Modify

Opened 13 months ago

Last modified 9 months ago

#18750 new enhancement

Use territories/boundaries for maps

Reported by: simon04 Owned by: team
Priority: normal Milestone:
Component: Core imagery Version:
Keywords: Cc: Klumbumbus

Description

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.

Attachments (0)

Change History (13)

comment:1 Changed 13 months ago by 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.

comment:2 Changed 13 months ago by 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.

comment:3 in reply to:  2 Changed 13 months ago by 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.

Last edited 13 months ago by stoecker (previous) (diff)

comment:4 Changed 12 months ago by 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.

comment:5 in reply to:  4 Changed 12 months ago by 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"?

comment:6 Changed 12 months ago by 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

comment:7 Changed 12 months ago by 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.

comment:8 in reply to:  7 ; Changed 12 months ago by stoecker

Cc: Klumbumbus added

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.

comment:9 in reply to:  8 ; Changed 12 months ago by 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.

comment:10 in reply to:  9 Changed 12 months ago by 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.

comment:11 Changed 12 months ago by 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.

comment:12 in reply to:  9 Changed 12 months ago by 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

comment:13 Changed 9 months ago by simon04

In 16559/josm:

fix #19356, see #18750 - Deduplicate ImageryBounds

Reduces retained size of ImageryBounds from 3_372_384 to 1_985_952

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to simon04
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.