Use territories/boundaries for maps

[simon04]

We could use the territories/boundaries.osm to define the <bounds> of Maps entries instead of repeatedly defining the boundaries of Austria, Germany, etc.

For Austria the following XML could be used:

<bounds iso3166-1='AT' min-lat='46.3785275' min-lon='9.5406306' max-lat='49.0126611' max-lon='17.1739737' />
<!-- or even shorter -->
<bounds iso3166-1='AT' />

The further question arises whether we'd want to refine our boundaries.osm for states such as AT-7 or DE-SN.

[stoecker]

I doubt that's a good idea:

• It adds a lot of complexity to the whole process
• It makes editing for users more complex
• Boundaries for imagery often is not identical with the political boundaries.

I know that sometimes instead of the real imagery bounds the political bounds are used, but this behaviour should not be encouraged.

[simon04]

I came up with this idea in the course of working on #18749. Currently, every map boundary shape of Austria requires extra memory in every JOSM instance running, nothing is deduplicated.

[stoecker]

Replying to simon04:

I came up with this idea in the course of working on #18749. Currently, every map boundary shape of Austria requires extra memory in every JOSM instance running, nothing is deduplicated.

Deduplication of identical shapes without touching the file format would be a fine goal.

In the transfered file duplicate shapes probably have no real effect as they will be compressed away.

[Don-vip]

iD just forked ELI into a new project: ​https://github.com/ideditor/imagery-index
The shapes are deduplicated, that makes entries management easier, we should find a similar solution.

[stoecker]

Replying to Don-vip:

iD just forked ELI into a new project: ​https://github.com/ideditor/imagery-index

Reading the first reactions - ELI people are pissed about the "How can he do that". Well, welcome in the club :-) They should be a bit more relaxed looking at their own history.

The shapes are deduplicated, that makes entries management easier, we should find a similar solution.

As said I'd prefer a solution which is on JOSM side, not in the wiki, as a wiki based variant will make changes much more complicated, but don't really reduce transmitted data size. We could also consider a solution at the "wiki compilation time".

Where do you see a "makes entries management easier"?

[stoecker]

Hmm, I'm pretty sure the new index is violating the license of JOSM and ELI index. The "It's not a fork - all the files are significantly changed and I went through each one by hand and reworked the geometry" sounds much like I sprayed a bit of holy water on it so it's not the same: ​https://github.com/openstreetmap/iD/issues/7425#issuecomment-597973373

[Don-vip]

The most cumbersome thing I have with managing entries is the size of text needed to be copied everytime an existing aerial source releases a new year (examples: Toulouse, Berlin, Frankfurt...). The area is often exactly the same, so I'd like to not have to copy all this data again in the new entry. The single imagery file created by ant imageryindexdownload is very huge and becomes more and more impractical to scroll with a text editor. Our wiki pages are also enormous and tend to make Firefox slowish too.

I don't like at all what Brian did by forking again the index, but I like the technical idea of splitting the geometries out of the imagery entries so that they can be combined and reused in them. I find it rather elegant and practical.

[stoecker]

Replying to Don-vip:

The most cumbersome thing I have with managing entries is the size of text needed to be copied everytime an existing aerial source releases a new year (examples: Toulouse, Berlin, Frankfurt...). The area is often exactly the same, so I'd like to not have to copy all this data again in the new entry.

There are several reasons I object:

Often the area is not exactly the same. Many image providers don't cut exactly at the borders but also provide data outside the own coverage area. These data sets change each time depending on the technical details of the imagery creation process. That means copying the data is actually not the right way, but usually only the easy way. It should not be encouraged.

If we use "extracted" boundaries than people will use them, because that's easier. This means efforts to create the real boundaries will be further reduced.

Extracted boundaries will be modified. These modifications will not check all the imagery but simply be done. Result will be that older imagery gets new boundaries, but these changes will not be justified.

The single imagery file created by ant imageryindexdownload is very huge and becomes more and more impractical to scroll with a text editor.

I agree. But that's a use case I don't see as a problem. :-)

Our wiki pages are also enormous and tend to make Firefox slowish too.

There is an easy fix for that: Splitting. The Per-Country choice is not technical, but only a practical one. If it gets unpractical we can further split (e.g. extract some large ones to own pages).

I don't like at all what Brian did by forking again the index

It's probably the worst thing which can be done, but I also understand it. ELI is simply not handling issues but ignoring them. That's no state which can last long.

but I like the technical idea of splitting the geometries out of the imagery entries so that they can be combined and reused in them. I find it rather elegant and practical.

Technical the solution is fine. I don't like it for purely non-technical reasons.

We could implement the solution Simon proposed in this ticket and drop the exact-match-boundaries, but also this I don't like much, as it has the same effect. People will be using this instead of proper defined boundaries simply because is much easier to write a country code than define a large boundary. And there is much backend work to be done, so that boundaries.osm data can be displayed in the wiki.

To improve editing I'd rather suggest something much more important:

• Support WMTS and remaining entries in OpenLayers preview
• Support creating and editing boundaries in the OpenLayers preview

That would really make work easier when you can directly edit the boundaries instead of having to use JOSM or any other software.

[Don-vip]

Replying to stoecker:

To improve editing I'd rather suggest something much more important:

• Support WMTS and remaining entries in OpenLayers preview
• Support creating and editing boundaries in the OpenLayers preview

That would really make work easier when you can directly edit the boundaries instead of having to use JOSM or any other software.

Good idea, it would indeed solve my problems too.

[stoecker]

Replying to Don-vip:

Replying to stoecker:

To improve editing I'd rather suggest something much more important:

• Support WMTS and remaining entries in OpenLayers preview
• Support creating and editing boundaries in the OpenLayers preview

That would really make work easier when you can directly edit the boundaries instead of having to use JOSM or any other software.

Good idea, it would indeed solve my problems too.

Here at work we do something similar, but I never had the time to implement that stuff for JOSM. If somebody could develop example OpenLayers code based on the preview we already have it would ease the workload of implementing that into the scripts a lot. As far as I known it's not really complicated, only a lot of docs and example code reading and testing.

It mainly needs:

• a way to add a new node
• a way to move a node
• a way to remove a node
• a button the send the final result to the server for data update.

[Klumbumbus]

No objections from my side to the different suggestions, as long as this doesn't lead to less precise shapes in the short or long term as feared in comment:8.

[stoecker]

• Support creating and editing boundaries in the OpenLayers preview

Possible workflow based on JOSM:

• Click on an empty place
  • create a new node
  • select that node
  • from now on draw a line to current cursor until next click
  • finish work when clicked on first node
• Click on a point and drag: move node
• Click on way and drag (at least a minimum distance): create a new node inside this way
• Click on a way and press <DEL>: ask for confirmation and delete way
• Click on a node and press <DEL>: delete node

[simon04]

In 16559/josm:

fix #19356, see #18750 - Deduplicate ImageryBounds

Reduces retained size of ImageryBounds from 3_372_384 to 1_985_952