Planned major restructure in ELI including a possible license change

[Klumbumbus]

See ​https://github.com/osmlab/editor-layer-index/pull/490
Please comment there if you have any comments.

[stoecker]

Hmm, after I checked when the OSM license change was I thought about fosm.org. They are still there. Even 6 years later they don't accept that it was a bad idea from the beginning and drop it.

[Don-vip]

Replying to stoecker:

fosm.org. They are still there.

lol I thought this project disappeared long ago. The ​What's Different? page is hilarious:

The fosm server platform is different and more technically advanced than OpenStreetMap. Rather than using a vast array of services spread across multiple servers, fosm runs on a single much smaller server. This is possible because we use a more sophisticated database and a very thin application layer.

Concerning ELI, I don't care. I just hope it does not mean more work for JOSM team / compare script.

[Don-vip]

Or is it already live and explaining the current ImageryCompare error?

Caught: java.lang.IllegalArgumentException: Illegal double value '[6.77881,46.80057]'
java.lang.IllegalArgumentException: Illegal double value '[6.77881,46.80057]'
        at org.openstreetmap.josm.data.imagery.Shape.addPoint(Shape.java:81)
        at org.openstreetmap.josm.data.imagery.Shape$addPoint.call(Unknown Source)
        at SyncEditorLayerIndex.getShapes(SyncEditorLayerIndex.groovy:988)
        at SyncEditorLayerIndex$getShapes.callStatic(Unknown Source)
        at SyncEditorLayerIndex.checkCommonEntries(SyncEditorLayerIndex.groovy:698)
        at SyncEditorLayerIndex$checkCommonEntries.call(Unknown Source)
        at SyncEditorLayerIndex.main(SyncEditorLayerIndex.groovy:86)
Caused by: java.lang.NumberFormatException: For input string: "[6.77881,46.80057]"
        at org.openstreetmap.josm.data.imagery.Shape.addPoint(Shape.java:77)
        ... 6 more

The script was failing due to #16249, I fixed it in r13767:13769, but there is the error above now.

[stoecker]

Replying to Don-vip:

The script was failing due to #16249, I fixed it in r13767:13769, but there is the error above now.

Hmm. That's broken. Preferences.init() calls getDefaultsCacheDir() which in JosmBaseDirectories.java accesses Config.getPref().

Either JosmBaseDirectories needs to be called with the pref directly or this must be decoupled in another way.

[stoecker]

The double value error (a "[" too much I assume) is now catched and printed.

[Don-vip]

Replying to stoecker:

Hmm. That's broken.

It should be better with r13775.

[Don-vip]

OK it's repaired now. 11 red entries.

[stoecker]

Replying to stoecker:

The double value error (a "[" too much I assume) is now catched and printed.

Seems that's due to usage of MultiPolygon GeoJSON type. We'd need to support that as well (which is easy, but only if this is also officially adopted for ELI).

I don't see yet why that's necessary, as we have multiple polygons already in some cases (or aren't they officially GeoJSON compatible?).

Actually over the years my view of ELI does not improve:

• permanent errors in data
• permanent changes in the repository structure
• instable output format
• no cooperation
• missing support of most new JOSM features

Syncing contains a lot of useless work due to these points. The ignore list grows instead of shrinking. Removed troubles are usually only due to Klumbumbus efforts.

For me ELI does everything which I wanted to avoid when introducing the JOSM wiki based solution and has no benefits I can see. The big ELI goal of peer review is worse than on JOSM side in my eyes.

[anonymous]

"permanent errors in data" maybe I am missing something, but is it reported at ​https://github.com/osmlab/editor-layer-index/issues ? I see nothing that fits this description.

[anonymous]

The ​What's Different? page is hilarious:

​http://map.fosm.org/#map/ in help | about has "It is currently (1 May 2015)" :)

[stoecker]

Replying to anonym:

"permanent errors in data" maybe I am missing something, but is it reported at ​https://github.com/osmlab/editor-layer-index/issues ? I see nothing that fits this description.

When entries are changed or added only in a minority of cases data can simply be synced/copied to JOSM. In most cases it requires cleanup, typo fixes, URL fixes, boundary fixes, ... Or complete changes which are even wrong like the recent reduction of the max-zoom or the "removal" of "/" from URLs. The most important cases Klumbumbus in self-defense backports to ELI, the others go into our ignore list or the script is adapted to ignore this type of difference always. The amount of work spent to keep the sync script error outputs to a reasonable level and the data synced as good as possible is immense.

And no, we don't open a ticket for each case. The Sync output is available for everybody to look at and it is automatically updated each time one of the two datasets is changed.

Beside this, additional work comes from differences, which are unnecessary and could be reduced when in case of JOSM → ELI sync the data would be copied 1:1 and not slightly modified (adding/removing "." at end of texts and alike).

[Don-vip]

It seems ELI added ​multipolygon data before ​supporting it. Yet another strange thing hard to understand...

[stoecker]

License change is no longer an issue - my arguments were accepted. If the scripts change we'll see what to do. As long as still a final geojson is peovided changes here should be minimal.

[Klumbumbus]

I (partly) synced this entry and now the ImageryCompare script fails again.

[Don-vip]

WARNING: Caught: java.lang.NullPointerException: Cannot invoke method size() on null object
java.lang.NullPointerException: Cannot invoke method size() on null object
        at java_util_List$size.call(Unknown Source)
        at SyncEditorLayerIndex.checkCommonEntries(SyncEditorLayerIndex.groovy:725)
        at SyncEditorLayerIndex$checkCommonEntries.call(Unknown Source)
        at SyncEditorLayerIndex.main(SyncEditorLayerIndex.groovy:86)

[Don-vip]

In 13780/josm:

see #16294 - fix NPE

[Don-vip]

Fixed :)

[Klumbumbus]

Thx!

[Klumbumbus]

Replying to stoecker:

Syncing contains a lot of useless work due to these points. The ignore list grows instead of shrinking.

Yes, this annoys me too. ImageryCompareIgnores is already the 5th most edited page in the whole JOSM wiki and will soon raise to rank 3 or 2!

[Klumbumbus]

@nkamapper:
you changed these URLs from jpeg to png in JOSM and at the same day you added the entries in ELI with jpeg. This produced these error at ImageryCompare:

* URL for id kartverket-dtm-skygge differs (https://wms.geonorge.no/skwms1/wms.hoyde-dtm_somlos_skyggerelieff?FORMAT=image/jpeg&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=las_dtm_skyggerelieff_somlos&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}): [NO] Kartverket DTM Digital Terrain Model - https://wms.geonorge.no/skwms1/wms.hoyde-dtm_somlos_skyggerelieff?FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=las_dtm_skyggerelieff_somlos&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
* URL for id kartverket-dom-skygge differs (https://wms.geonorge.no/skwms1/wms.hoyde-dom_somlos_skyggerelieff?FORMAT=image/jpeg&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=las_dom_skyggerelieff_somlos&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}): [NO] Kartverket DOM Digital Surface Model - https://wms.geonorge.no/skwms1/wms.hoyde-dom_somlos_skyggerelieff?FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=las_dom_skyggerelieff_somlos&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

Please when you make changes or additions in JOSM or ELI keep them in sync and check this page for red marked errors/conflicts and try to resolve them.