ngageoint / hootenanny

Hootenanny conflates multiple maps into a single seamless map.
GNU General Public License v3.0
356 stars 74 forks source link

Schema Switcher Service, Craziness #1937

Open NickolasTobin opened 7 years ago

NickolasTobin commented 7 years ago

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:


<osm version='0.6' generator='JOSM'>
  <way id='446097462' timestamp='2016-10-06T12:32:34Z' uid='4016148' user='Fl0ra' visible='true' version='1' changeset='42682950'>
    <nd ref='4434275531' />
    <nd ref='4434275532' />
    <nd ref='4434275533' />
    <nd ref='4434275534' />
    <nd ref='4434275531' />
    <tag k='building' v='yes' />
  </way>
</osm>

2017-11-02 11:56:14.263 INFO: POST https://nome.vgihub.geointservices.io/switcher/translateTo?translation=TDSv61 (396 B) ...
2017-11-02 11:56:17.429 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="-49" timestamp="2016-10-06T12:32:34Z" version="1" changeset="42682950" user="Fl0ra" uid="4016148">
        <tag k="UFI" v="43a79714-26d6-4a27-8c78-a9898ae17cd7"/>
        <tag k="F_CODE" v="AL013"/>
        <tag k="ZI001_SDV" v="2016-10-06T12:32:34Z"/>
    </way>
</osm>```

Notice the TDSv40.  Now I leave it to the person receiving this to translate 
any 10 or so of the buildings in sample.osm.. you get all kinds of different 
results.. the second is whether you get a FCSUBTYPE when translated.. 
which seems random.

Suddenly I cannot cause the TDSv40 thing to happen. Some real oddness here.
NickolasTobin commented 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>```
NickolasTobin commented 7 years ago

screenshot from 2017-11-02 21-28-26

Multiple translations of this road reveal that FCSUBTYPE is sometimes not populated when going to TDSv61.

brianhatchl commented 6 years ago

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).

brianhatchl commented 6 years ago

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

mattjdnv commented 6 years ago

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.