SASGIS - SAS.Планета
View Issue Details
0001464SAS.Планета[All Projects] Багpublic07-08-2012 07:3307-08-2012 11:00
Fetser 
vasketsov 
normalminoralways
closednot fixable 
WindowsXPSP3
.Nightly 
 
0001464: В версии 120807.6241 не работает импорт некоторых видов kmz
В версии 120807.6241 не работает импорт некоторых видом kmz. В предыдущих импорт данного kmz работал.
No tags attached.
? 1.kmz (5,758) 07-08-2012 07:33
https://bugtracker.sasgis.org/file_download.php?file_id=899&type=bug
Issue History
07-08-2012 07:33FetserNew Issue
07-08-2012 07:33FetserFile Added: 1.kmz
07-08-2012 07:36vdemidovAssigned To => vasketsov
07-08-2012 07:36vdemidovStatusnew => assigned
07-08-2012 07:36vdemidovTarget Version => 120808
07-08-2012 08:08TolikSummaryв версии 120807.6241 не работает импорт некоторых видом kmz => В версии 120807.6241 не работает импорт некоторых видов kmz
07-08-2012 09:04vasketsovNote Added: 0008174
07-08-2012 09:05vasketsovStatusassigned => feedback
07-08-2012 09:20vdemidovNote Added: 0008175
07-08-2012 09:43vasketsovNote Added: 0008176
07-08-2012 09:45vasketsovNote Edited: 0008176bug_revision_view_page.php?bugnote_id=8176#r3908
07-08-2012 09:48zedNote Added: 0008177
07-08-2012 10:05vdemidovNote Added: 0008183
07-08-2012 10:57FetserNote Added: 0008195
07-08-2012 10:57FetserStatusfeedback => assigned
07-08-2012 10:59vdemidovNote Added: 0008196
07-08-2012 11:00vdemidovStatusassigned => resolved
07-08-2012 11:00vdemidovResolutionopen => not fixable
07-08-2012 11:00vdemidovStatusresolved => closed
07-08-2012 11:00vdemidovTarget Version120808 =>

Notes
(0008174)
vasketsov   
07-08-2012 09:04   
Тэг <coordinates> по стандарту kml
https://developers.google.com/kml/documentation/kmlreference?hl=ru
бывает только внутри:
а) <Point>;
б) <LinearRing> (внутри <outerBoundaryIs> и <innerBoundaryIs>);
в) <LineString>;
г) <gx:LatLonQuad> внутри <GroundOverlay>.

Внутри <Polygon> указание <outerBoundaryIs> является обязательным.

В приаттаченном kml мы наблюдаем:
<Placemark>
<name>11</name>
<Polygon>
<coordinates>-180,71.9968938728948,0 -176.0888671875,71.3891881330282,0 -179.6484375,69.7364422857331,0 -167.958984375,66.4081977854982,0 -173.1005859375,63.6820844439265,0 -177.5390625,64.9220510886106,0 -180,64.659690253763,0 -180,71.9968938728948,0 </coordinates>
</Polygon>
</Placemark>

Вывод - он работал по недоразумению.

Вопросы:
1. Откуда такой kml взялся?
2. Надо ли делать поддержку таких нестандартных kml (в приницпе конкретно это сделать просто)?
(0008175)
vdemidov   
07-08-2012 09:20   
ИМХО похожие случаи должны работать.
(0008176)
vasketsov   
07-08-2012 09:43   
(edited on: 07-08-2012 09:45)
Похожие на что?
А если прямо в Folder-е будет coordinates? ))))

В вопросе 2 под "таких" понимается "kml из источников кривых kml из ответа 1".
То есть, хотелось бы понять, какие именно отступления от стандарта имеет смысл обрабатывать как корректную ситуацию. Насколько кривые kml будем пытаться импортировать.

зы. Чтобы вылечить конкретно это отступление от стандарта - надо реально 1 минуту, как только загружу проект - так сразу и прикручу.

(0008177)
zed   
07-08-2012 09:48   
Вначале, нужен ответ на вопрос №1.

У меня этот kml даже GE не хочет показывать (хотя открывает).
(0008183)
vdemidov   
07-08-2012 10:05   
Убедили. Если это безобразие генерит не слишком популярная программа, то лучше следовать стандарту, благо для kml он доступен и более менее очевиден.
(0008195)
Fetser   
07-08-2012 10:57   
>1. Откуда такой kml взялся?
Это упрощённый вручную KML. Я его использовал поскольку программа его легко понимала. Если там есть принципиальная ошибка можно и не делать поддержку. Я такие просто старой версией программы переведу в более привычный формат. У меня таких файлов всего несколько штук.
(0008196)
vdemidov   
07-08-2012 10:59   
Ну раз так, то можно закрывать.