Add map type definition to XML

[stoecker]

Should we add map and aerial/satellite image flags too. I think every source can be assigned to one of these three types. Displaying a little icon for the flag in wiki:Help/Preferences/Imagery would be nice and easier to understand what an entry is about.

See 14655#comment:91.

Current Suggestion: add an property "category" with supported values "photo", "map", "historicmap", "osmbasedmap", "historicphoto" and "other".

[Klumbumbus]

Replying to stoecker:

Suggestion: add an property "type" with supported values "photo" and "map".

and maybe "gps" (thinking of the strava heatmaps)
The overlay flag needs to be separate then, as both gps and map can be a overlay or not.

[stoecker]

Well, I don't like "gps", as its outdated. In geodesy we use GNSS, but nobody outside the business knows what that is. Better term: "track", "measurement"?

Type is already taken BTW. We need something else as well: "variant", "class"?

[Klumbumbus]

Replying to stoecker:

Well, I don't like "gps", as its outdated. In geodesy we use GNSS, but nobody outside the business knows what that is. Better term: "track", "measurement"?

This is maybe a bit out of scope of this ticket. We use "gps" all over in JOSM. A Launchpad search for "gps" gives 129 results. I think this must be decided later global for whole JOSM. Maybe the term GNSS becomes more popular one day when galileo is widespread used.

[Don-vip]

"Other" would be fine. There won't be a lot.

[Klumbumbus]

Replying to Don-vip:

"Other" would be fine. There won't be a lot.

sources, which come to my mind for "other":

• OpenStreetMap GPS Traces
• Strava cycling heatmap
• Strava running heatmap
• Strava cycling and running heatmap
• Strava water sports heatmap
• Strava winter sports heatmap
• LPI NSW Imagery Dates (--> in australia, shows the date when the imagery was taken)

I think these rather count as "map" and "overlay":

• Locator Overlay
• QA No Address
• OSM Inspector: Geometry
• OSM Inspector: Tagging
• OSM Inspector: Places
• OSM Inspector: Highways
• OSM Inspector: Area
• OSM Inspector: Routing
• OSM Inspector: Addresses
• OSM Inspector: Coastline (EU)
• OSM Inspector: Public Transport - Stops
• OSM Inspector: Public Transport - Routes
• OSM Inspector: Water

[Klumbumbus]

We would need a type "multiple" too for wms_endpoint entries, which provide "map" and "photo" (and "other").

And what about a flag "osm_based" for sources based (mainly) on osm data?

• osm inspector entries
• QA No Address
• Opencyclemap
• openrailwaymap
• stamen
• waymarked trails
• carto
• Cambodia, Laos, Thailand, Vietnam, Malaysia, Myanmar bilingual
• ...

[anonymous]

Also "historic" would be important to be able to filter these maps. But I also don't want more than one value for this.

My suggestion: "kind"
historicmap, osmmap, map, photo, other

[stoecker]

Last was me. Regarding mixed: simply don't specify a value?

[Klumbumbus]

Replying to stoecker:

Regarding mixed: simply don't specify a value?

Then you don't know if it is mixed or not yet specified.

[Klumbumbus]

aahh, https://josm.openstreetmap.de/mapsview?entry=Lantm%C3%A4teriet%20Economic%20Map%20%28historic%29 is a semitransparent map on historic aerial image :o

[stoecker]

Current list: "kind"
historicmap, map, osmbasedmap, historicphoto, photo, other
That's it (for now)?

[stoecker]

Replying to Klumbumbus:

Replying to stoecker:

Regarding mixed: simply don't specify a value?

Then you don't know if it is mixed or not yet specified.

ATM I think that's acceptable. If really necessary we can add types later.

[Klumbumbus]

For photo one could distinguish between true color and false color (infrared in most cases). But that would required an separate attribute again as it is independed from if the photo is historic or not.

What exactly means historic? Everything where a newer variant is available?

[Klumbumbus]

see also ​https://github.com/osmlab/editor-layer-index/issues/136

[stoecker]

From the ELI ticket I'd take suggestion "category" for the key.

category: historicmap, map, osmbasedmap, historicphoto, photo, other

[stoecker]

Sorry, forgot to answer last time.

Replying to Klumbumbus:

For photo one could distinguish between true color and false color (infrared in most cases). But that would required an separate attribute again as it is independed from if the photo is historic or not.

Mostly the Infrared is already in the name. I still think that overdoing the categorization will do more harm than good.

I try to imagine use cases in the editor for filtering

• historic: use case should be clear
• osmbasedmap: I.e. I don't want to see derivates
• map/photo: I only care for imagery.

What use case would color specification or finer details allow as a generic filter?

What exactly means historic? Everything where a newer variant is available?

I'd say so. And anything which is at least 20 years old :-)

[stoecker]

Update description

[marc_marc]

I like map, osmbasedmap, photo, other
For historicmap, is the date field not sufficient to define the historical character or not which can vary according to the use?

[Klumbumbus]

historic... makes sense to me. E.g. in saxony we have 3 aerial imageries: latest, 2012-2014, 2005. While the imagery from 2014 is only 4 years old it should be categorized as historic as there is a newer variant from the same provider available (latest). If we want to filter out historic imageries then we would filter out the 2012-2014 imagery if categorizes as historic. Judging only from the date much likely we would't filter out a 4 year old imagery.

[stoecker]

Replying to marc_marc:

I like map, osmbasedmap, photo, other
For historicmap, is the date field not sufficient to define the historical character or not which can vary according to the use?

If you have map from 2017, 2016, 2015, 2014 the date field does not help, as <2016 are all historic. If the map is from 18xx then historic is clear. Same for photo. And as we want to prevent additional flags and specifications these addition types are designed.

[marc_marc]

so historic mean not-the-lastest one ?
should it's better to add a key lastest=no when a newer variant is available in stead of calling it "historic" ?
or outdatedmap or notlastedmap if you want 2 into 1 value
beacause in osm, historic is not for 2 years old feature

[stoecker]

Replying to marc_marc:

so historic mean not-the-lastest one ?
should it's better to add a key lastest=no when a newer variant is available in stead of calling it "historic" ?

That need another specification and I want to avoid this.

or outdatedmap or notlastedmap if you want 2 into 1 value
beacause in osm, historic is not for 2 years old feature

Sounds ugly. "historic" is more clear in my eyes.

[stoecker]

In 13792/josm:

fix #16103 - add map type definitions

[stoecker]

Note: That change will break ImageryCompare until tomorrow mornig :-)

[Klumbumbus]

follow up in #16301

[Don-vip]

In 13796/josm:

see #16103 - checkstyle