Open NickolasTobin opened 7 years ago
Over time, two different translations for the exact same data:
<osm version='0.6' generator='JOSM'>
<way id='446097421' timestamp='2016-10-06T12:32:33Z' uid='4016148' user='Fl0ra' visible='true' version='1' changeset='42682950'>
<nd ref='4434271351' />
<nd ref='4434271352' />
<nd ref='4434271353' />
<nd ref='4434271354' />
<nd ref='4434271351' />
<tag k='building' v='yes' />
</way>
</osm>
2017-11-02 14:53:37.715 INFO: POST https://nome.vgihub.geointservices.io/switcher/translateTo?translation=TDSv61 (396 B) ...
worked
worked
2017-11-02 14:53:40.530 INFO: POST https://nome.vgihub.geointservices.io/switcher/translateTo?translation=TDSv61 -> 200
response: <?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="hootenanny" srs="+epsg:4326">
<way visible="true" id="-35" timestamp="2016-10-06T12:32:33Z" version="1" changeset="42682950" user="Fl0ra" uid="4016148">
<tag k="UFI" v="63b524a7-d3d2-4fb9-bee3-c10cc6072db3"/>
<tag k="F_CODE" v="AL013"/>
<tag k="ZI001_SDV" v="2016-10-06T12:32:33Z"/>
<tag k="FCSUBTYPE" v="100083"/>
</way>
</osm>
and then:
<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' generator='JOSM'>
<way id='446097421' timestamp='2016-10-06T12:32:33Z' uid='4016148' user='Fl0ra' visible='true' version='1' changeset='42682950'>
<nd ref='4434271351' />
<nd ref='4434271352' />
<nd ref='4434271353' />
<nd ref='4434271354' />
<nd ref='4434271351' />
<tag k='building' v='yes' />
</way>
</osm>
2017-11-02 15:01:04.432 INFO: POST https://nome.vgihub.geointservices.io/switcher/translateTo?translation=TDSv61 (396 B) ...
worked
worked
worked
worked
worked
worked
2017-11-02 15:01:10.630 INFO: POST https://nome.vgihub.geointservices.io/switcher/translateTo?translation=TDSv61 -> 200
response: <?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="hootenanny" srs="+epsg:4326" schema="TDSv40">
<way visible="true" id="-55" timestamp="2016-10-06T12:32:33Z" version="1" changeset="42682950" user="Fl0ra" uid="4016148">
<tag k="UFI" v="a5a4123b-8072-4722-8660-5e35c59fce77"/>
<tag k="F_CODE" v="AL013"/>
<tag k="ZI001_SDV" v="2016-10-06T12:32:33Z"/>
</way>
</osm>```
Multiple translations of this road reveal that FCSUBTYPE is sometimes not populated when going to TDSv61.
Sometimes to TDSv40 sometimes to TDSv61 and sometimes returning no clear schema in the tagging.
This may have been fixed here https://github.com/ngageoint/hootenanny/pull/1965/files#diff-13712bd59e5c9e08bf492eafb6bb309bR289
The older code loaded the translation op source file with every request (which caused a performance hit) but may also have contributed to unexpected behavior of the schema attribute when not explicitly set before osm writing (was set internally when the translation was loaded).
I am not sure why FCSUBTYPE
is creeping into some of the translation results. I don't think this should ever happen.
I'm also surprised by the translation rule that seems to take a timestamp
attribute on the osm feature and convert that to an explicit tag ZI001_SDV
which is Source Date and Time
.
cc: @mattjdnv
Adding the FCSUBTYPE can be turned off:
// Turn off the ESRI FCSUBTYPE
hoot.Settings.set({"ogr.esri.fcsubtype":"false"});
Looking at this and some other translation funkyness, I think I should flip some of the tests around so that they work cleanly for the UI but require config settings for shapefile/fgdb export.
Second Edit: there are two problems... the source tag problem, and instability in translation
Edit: If there is a source tag, translation behaves differently to TDSv61. Check a building with and without a source you get oddly different results.
Using sample.osm, and translating individual buildings, it has come to my attention that when switching from OSM to TDSv61 you get multiple outcomes. Sometimes to TDSv40 sometimes to TDSv61 and sometimes returning no clear schema in the tagging. Example 1: