[Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Dear All, I hope this note is not too off topic. In order to maintain/improve the data quality for our mobile application, I have been thinking about ways we can efficiently verify data for refill points for drinking water at fountains participating refill cafes, bars and other establishments. One idea I had was to create a map with possible stale refill cafes (and rural fountains) for volunteers to verify. Please find attached a draft note for a feature proposal, which I have no idea if is even technically possible, for automatically adding a last verified date/creation date to specific keys. Maybe there is a better/more efficient way ? https://drive.google.com/open?id=1MWSFfRBzA59i7wCeo-SLh4Cr1JxOh1Zo If others believe the draft note can be a useful basis for a generalize discussion on the topic of data staleness within OpenStreetMap, I will create a wiki. Best regards, Stuart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hello Stuart, may I suggest that you choose a personal email address for participating in mailing lists. It feels really strange to address a message to "europeanwaterproject". I don't want to talk with "a project", I want to talk with a person. On 06.04.20 09:31, European Water Project wrote: > Please find attached a draft note for a feature proposal, which I have > no idea if is even technically possible, for automatically adding a last > verified date/creation date to specific keys. Maybe there is a > better/more efficient way ? There are several issues here. Firstly, I don't know what you mean by "automatically adding". After all you need a person to manually confirm that the object is unchanged before a tag is added, so which part of this is automatic? Surely you are not saying that you want to add a tag to every object that simply duplicates the last-edit timestamp already stored? Secondly, this is a problem shared by all the "last survey" approaches: You're standing the logic on its head. You're essentially saying: "If the object has NOT changed in reality, please DO change it in OSM" (by updating the last-checked tag). This means that we're being asked to switch from mapping changes to mapping non-changes, with a potentially huge data inflation in OSM (in theory I could update the "last survey" of my local supermarket every time I shop there...). Your idea to identify potentially fast-changing things and concentrate on these softens the impact but still, we'd be churning out new versions of objects like crazy just to confirm they are still there. (Everytime you make a little change to one of the object's 10 tags, a full copy of the object is created in OSM.) Thirdly, also shared by many "last survey" approaches: If you tag a restaurant with a last survey date then exactly what have you surveyed? Just that it is still there? That is still has these opening hours? Or that it still gives you free water? There's potential from confusion here. The topic of staleness has been attacked by scientists in the past, trying statistical approaches along the lines of "if there's a decent number of detailed edits by different people in this area, then there is a high probability of data being up to date". This of course doesn't give you the same reliability but perhaps it delivers some results without being the massively invasive concept you're proposing. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
On Mon, 6 Apr 2020 at 10:14, Frederik Ramm wrote: > Dear Frederick, > > may I suggest that you choose a personal email address for participating > in mailing lists. It feels really strange to address a message to > "europeanwaterproject". I don't want to talk with "a project", I want to > talk with a person. > I am a person not a robot :) Thank you for the suggestion. > > On 06.04.20 09:31, European Water Project wrote: > > Please find attached a draft note for a feature proposal, which I have > > no idea if is even technically possible, for automatically adding a last > > verified date/creation date to specific keys. Maybe there is a > > better/more efficient way ? > > There are several issues here. > > Firstly, I don't know what you mean by "automatically adding". After all > you need a person to manually confirm that the object is unchanged > before a tag is added, so which part of this is automatic? Surely you > are not saying that you want to add a tag to every object that simply > duplicates the last-edit timestamp already stored? > You are right. It would be ludicrous to add a datestamp tag to ever object key, but having access to last changed/verified meta data for particular key tags would be useful. > > Secondly, this is a problem shared by all the "last survey" approaches: > You're standing the logic on its head. You're essentially saying: "If > the object has NOT changed in reality, please DO change it in OSM" (by > updating the last-checked tag). This means that we're being asked to > switch from mapping changes to mapping non-changes, with a potentially > huge data inflation in OSM (in theory I could update the "last survey" > of my local supermarket every time I shop there...). Your idea to > identify potentially fast-changing things and concentrate on these > softens the impact but still, we'd be churning out new versions of > objects like crazy just to confirm they are still there. (Everytime you > make a little change to one of the object's 10 tags, a full copy of the > object is created in OSM.) > I am not "saying" anything. I am brainstorming about whether or not storing updated meta data for a key being verified can be maintained without the OSM object being modified. > > Thirdly, also shared by many "last survey" approaches: If you tag a > restaurant with a last survey date then exactly what have you surveyed? > Just that it is still there? That is still has these opening hours? Or > that it still gives you free water? There's potential from confusion here. > The draft proposal was on the key level not the object level for just this reason. > > The topic of staleness has been attacked by scientists in the past, > trying statistical approaches along the lines of "if there's a decent > number of detailed edits by different people in this area, then there is > a high probability of data being up to date". This of course doesn't > give you the same reliability but perhaps it delivers some results > without being the massively invasive concept you're proposing. > I believe there will be better data quality for high use observable/verifiable data than rarely used data or data that cannot be observed at all (ie third party sourced data, the presence of a café in a small town with few visitors, or the name of the author of an artwork). > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Urgent Care
Le 05.04.20 à 17:06, Ty Stockman a écrit : > https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care > The urgent care tag is used at, for example, clinics, that offer walk-in > service isn't "walk-in" already included in reservation=no ? and/or with emergency=yes ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Am Mo., 6. Apr. 2020 um 10:13 Uhr schrieb Frederik Ramm : > Secondly, this is a problem shared by all the "last survey" approaches: > You're standing the logic on its head. You're essentially saying: "If > the object has NOT changed in reality, please DO change it in OSM" (by > updating the last-checked tag). This means that we're being asked to > switch from mapping changes to mapping non-changes, with a potentially > huge data inflation in OSM (in theory I could update the "last survey" > of my local supermarket every time I shop there...). Your idea to > identify potentially fast-changing things and concentrate on these > softens the impact but still, we'd be churning out new versions of > objects like crazy just to confirm they are still there. (Everytime you > make a little change to one of the object's 10 tags, a full copy of the > object is created in OSM.) > I agree that the last survey date approach where "ordinary" tags are set, are crazy. On the other hand, it seems to be a topic that a significant number of contributors are interested in (currently ~710.000 tags for this). To do it better, maybe it could be stored in parallel? There is this long wish list for API 0.7 in the wiki ;-) https://wiki.openstreetmap.org/wiki/API_v0.7 Likely it would not be something to be implemented in the next 10 years or so, but at least it could be kept track of the idea and people could be pointed to it... There could be another table which stores for every tag on every object a confirmation date (by explicit request, i.e. it would only be set when a contributor explicitly sets it on a tag on an object, and when objects are split these would have to be split as well). This would imply that no new object version is created for simple property confirmations that do not alter the object. > > Thirdly, also shared by many "last survey" approaches: If you tag a > restaurant with a last survey date then exactly what have you surveyed? > Just that it is still there? That is still has these opening hours? Or > that it still gives you free water? There's potential from confusion here. yes, the last survey confirmations would have to be stored on tag level, not on object level. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Dear Martin, A date uses 3-4 bytes of memory. Just for brainstorming purposes, what would be the total database size inflation if all keys on all nodes, ways and relations in OpenStreetMap had 4 extra bytes of date meta data ? Best regards, Stuart On Mon, 6 Apr 2020 at 11:42, Martin Koppenhoefer wrote: > Am Mo., 6. Apr. 2020 um 10:13 Uhr schrieb Frederik Ramm < > frede...@remote.org>: > >> Secondly, this is a problem shared by all the "last survey" approaches: >> You're standing the logic on its head. You're essentially saying: "If >> the object has NOT changed in reality, please DO change it in OSM" (by >> updating the last-checked tag). This means that we're being asked to >> switch from mapping changes to mapping non-changes, with a potentially >> huge data inflation in OSM (in theory I could update the "last survey" >> of my local supermarket every time I shop there...). Your idea to >> identify potentially fast-changing things and concentrate on these >> softens the impact but still, we'd be churning out new versions of >> objects like crazy just to confirm they are still there. (Everytime you >> make a little change to one of the object's 10 tags, a full copy of the >> object is created in OSM.) >> > > > I agree that the last survey date approach where "ordinary" tags are set, > are crazy. On the other hand, it seems to be a topic that a significant > number of contributors are interested in (currently ~710.000 tags for > this). To do it better, maybe it could be stored in parallel? There is this > long wish list for API 0.7 in the wiki ;-) > https://wiki.openstreetmap.org/wiki/API_v0.7 > Likely it would not be something to be implemented in the next 10 years or > so, but at least it could be kept track of the idea and people could be > pointed to it... > > There could be another table which stores for every tag on every object a > confirmation date (by explicit request, i.e. it would only be set when a > contributor explicitly sets it on a tag on an object, and when objects are > split these would have to be split as well). This would imply that no new > object version is created for simple property confirmations that do not > alter the object. > > > > >> >> Thirdly, also shared by many "last survey" approaches: If you tag a >> restaurant with a last survey date then exactly what have you surveyed? >> Just that it is still there? That is still has these opening hours? Or >> that it still gives you free water? There's potential from confusion here. > > > > yes, the last survey confirmations would have to be stored on tag level, > not on object level. > > Cheers > Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hello, Le 06.04.20 à 09:31, European Water Project a écrit : > I have been thinking about ways we can efficiently verify data here's my workflow : - once a year, I query all poi (bar, restaurant, shop) within my comfort zone, and check all tag again. if nothing change, I update the tag survey:date=-MM on it of course the main problem occurs when everything is not checked (does the wifi work?) or verifiable (does the fire hydrant work?). for this last point, during the proposal on fire hydrants, we had agreed to use operational_status:date, for this king of technical object, it's fine. for a test of the restaurant wifi, it's not ideal, maybe not even desirable for opening jours, I don't know what to use. seeing the restaurant (source=survey) doesn't say clearly what was seen, was it just the fact that the restaurant was open? also the name ? or all the tags like I do ? of course one solution is to put lots of tag1:date tag2:date I hate this because the next contributor will modify tag1 without necessarily modifying tag1:date (it's the same problem with the source tag on objects that informs the source used by the one who added the object and not the source of the current object, with sometimes big difference such as a change of poi type) Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hi Marc, I am convinced survey:date is not the solution for maintaining large swathes of OpenStreetMap data. Nor do I think putting a survey date at a per tag level is realistic or workable. Best regards, Stuart On Mon, 6 Apr 2020 at 12:24, Marc M. wrote: > Hello, > > Le 06.04.20 à 09:31, European Water Project a écrit : > > I have been thinking about ways we can efficiently verify data > > here's my workflow : > - once a year, I query all poi (bar, restaurant, shop) within my comfort > zone, and check all tag again. > if nothing change, I update the tag survey:date=-MM on it > > of course the main problem occurs when everything is not checked (does > the wifi work?) or verifiable (does the fire hydrant work?). > for this last point, during the proposal on fire hydrants, we had agreed > to use operational_status:date, for this king of technical object, it's > fine. > for a test of the restaurant wifi, it's not ideal, maybe not even desirable > for opening jours, I don't know what to use. > seeing the restaurant (source=survey) doesn't say clearly what was seen, > was it just the fact that the restaurant was open? also the name ? > or all the tags like I do ? > of course one solution is to put lots of tag1:date tag2:date > I hate this because the next contributor will modify tag1 without > necessarily modifying tag1:date (it's the same problem with the source > tag on objects that informs the source used by the one who added the > object and not the source of the current object, with sometimes big > difference such as a change of poi type) > > Regards, > Marc > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
On 6/4/20 9:23 am, Joseph Eisenberg wrote: The only thing that the proposal page still needs is a couple more detailed definitions for some of the tags. Maybe not. A quick read finds this statement: protect_class=2 will be tagged as boundary=national_park (de facto) This is a problem because boundary=national_park already exists as a generic tag for a conservation area. A quick survey of all of the existing boundary=national_park with a wikidata link finds the following range of IUCN Protected Area Categories: Class Count IA 95 IB 70 II 848 III 74 IV 277 V 234 VI 159 Total 1757 So less than 50% of "National Parks" are Cat II. I would suggest adding protection_class=national_park and dropping the suggestion of using boundary=national_park. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Refugee Site Location
Dear all, Thank you Joseph and Stuart for your very valuable comments, these exchanges are very constructive and personally I learn a lot about how OSM database works. I agree with both of you, it seems more appropriate to use a node or a polygon main top-level key. And it’s true we have this constraint of being able to map the refugee site with either node or polygon (Polygon being preferable when possible, but sometimes it’s impossible to delimit clearly the exact area.) I will try to resume the options we have left: First, it’s agreed that the distinction between large and small (less than 5 buildings) refugee site is necessary. For small refugee site, the use of the existing Amenity=social_facility + social_facility=shelter + social_facility:for= ""> Does not seem to be a problem For large refugee site we still have different options Option 1: The key refugee_site=yes is added to a place tag Place = neighbourhood/suburb/village/town + refugee_site=yes + refugee_site:XX=XX -> but if I understand well, it’s not possible to tag a polygon with the tag place? if so this option is not relevant to map refugee_site as polygon. also it not so easy to identify if the refugee site should be map as a neighbourhood or a suburb or a village or a town. And as Jorieke said, it’s seems complicated to apply this to all context as she illustrated very well. Option 2: The key refugee_site=yes is added to a landuse tag Landuse = residential + refugee_site=yes + refugee_site:XX=XX -> But if I understand correctly, the use of landuse=residential is not always adapted to the refugee site (landuse=residential area, ideally, should only include areas that are primarily residential). Also it would be wrong to create a new residential area to delimit a refugee site already inside a larger residential area. Thus this option seems a bit problematic. QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily have to be associated with place or landuse? And if we could have refugee_site=yes without any other tags ? in this case the limits cited above would no longer be constraining. but if I understand you Joseph, this will be a problem for the rendering ? Option 3: use an existing main top-level key (from the listed options shared by Joseph) My preference as Joseph and Oukasz would be for the Amenity option, as it can apply as well as a node or a polygon, and fit better with the option for small refugee site. Amenity=refugee_site + refugee_site:XX=XX QUESTION: I still have 2 questions. With this option could we still proposed the secondary tags refugee_site:XX=XX (for instance refugee_site:status=formal)? As those secondary tag are very important too as mentioned in the talk page and because the diversity of refugee_site is such that it’s important to be able to detail the characteristics of it. Do we also have to add “refugee_site=yes” or it’s not necessary? About rendering: for sure it’s good to take it into account, but I think it’s not a priority, the most important is to ensure a consistency in the way to map refugee site in OSM and to facilitate data extraction and data maintenance. I have a more practical question, as the proposition change a lot, what is best, create a new proposed feature page “refugee Site Location 3” or can I change the “refugee Site Location 2” page ? Thank you for your participation Have a great day, Manon Manon Viou Coordinatrice projet Missing Maps m_v...@cartong.org | manon.viou +33 (0)4 79 26 28 82 | +33 (0)7 83889839 Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Urgent Care
Honestly, reservation is definitely the wrong wording here, and so is emergency (see talk page of proposal) however, tag as you wish. From: Marc M. Sent: Monday, April 6, 2020 2:27 AM To: tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - Urgent Care Le 05.04.20 à 17:06, Ty Stockman a écrit : > https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care > The urgent care tag is used at, for example, clinics, that offer walk-in > service isn't "walk-in" already included in reservation=no ? and/or with emergency=yes ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Refugee Site Location
> QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily > have to be associated with place or landuse? As mentioned, it would be fine to use a new "key" like "refugee_site" for a feature that is only mapped as nodes, but if it is going to be used on areas it's important to use a well-known, established key. It's not just important for rendering, but also for routing and search applications, which also need to know if a closed way is representing an area or not. > QUESTION: IWith this option [amenity=refugee_site] could we still proposed > the secondary tags refugee_site:XX=XX (for instance > refugee_site:status=formal)? Yes. > Do we also have to add “refugee_site=yes” or it’s not necessary? No, if the tag is "amenity=refugee_site", there is no need to add it. -- Joseph Eisenberg On 4/6/20, Manon Viou wrote: > Dear all, > > Thank you Joseph and Stuart for your very valuable comments, these exchanges > are very constructive and personally I learn a lot about how OSM database > works. > > I agree with both of you, it seems more appropriate to use a node or a > polygon main top-level key. And it’s true we have this constraint of being > able to map the refugee site with either node or polygon (Polygon being > preferable when possible, but sometimes it’s impossible to delimit clearly > the exact area.) > > I will try to resume the options we have left: > > First, it’s agreed that the distinction between large and small (less than 5 > buildings) refugee site is necessary. > > For small refugee site, the use of the existing > Amenity=social_facility > + social_facility=shelter > + social_facility:for= internally_displaced/refugee > Does not seem to be a problem > > For large refugee site we still have different options > > Option 1: The key refugee_site=yes is added to a place tag > Place = neighbourhood/suburb/village/town > + refugee_site=yes > + refugee_site:XX=XX > -> but if I understand well, it’s not possible to tag a polygon with the tag > place? if so this option is not relevant to map refugee_site as polygon. > also it not so easy to identify if the refugee site should be map as a > neighbourhood or a suburb or a village or a town. And as Jorieke said, it’s > seems complicated to apply this to all context as she illustrated very well. > > Option 2: The key refugee_site=yes is added to a landuse tag > Landuse = residential > + refugee_site=yes > + refugee_site:XX=XX > -> But if I understand correctly, the use of landuse=residential is not > always adapted to the refugee site (landuse=residential area, ideally, > should only include areas that are primarily residential). Also it would be > wrong to create a new residential area to delimit a refugee site already > inside a larger residential area. Thus this option seems a bit problematic. > > QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily > have to be associated with place or landuse? And if we could have > refugee_site=yes without any other tags ? in this case the limits cited > above would no longer be constraining. > but if I understand you Joseph, this will be a problem for the rendering ? > > Option 3: use an existing main top-level key (from the listed options shared > by Joseph) > > My preference as Joseph and Oukasz would be for the Amenity option, as it > can apply as well as a node or a polygon, and fit better with the option for > small refugee site. > Amenity=refugee_site > + refugee_site:XX=XX > QUESTION: I still have 2 questions. With this option could we still proposed > the secondary tags refugee_site:XX=XX (for instance > refugee_site:status=formal)? As those secondary tag are very important too > as mentioned in the talk page and because the diversity of refugee_site is > such that it’s important to be able to detail the characteristics of it. > Do we also have to add “refugee_site=yes” or it’s not necessary? > > > About rendering: for sure it’s good to take it into account, but I think > it’s not a priority, the most important is to ensure a consistency in the > way to map refugee site in OSM and to facilitate data extraction and data > maintenance. > > I have a more practical question, as the proposition change a lot, what is > best, create a new proposed feature page “refugee Site Location 3” or can I > change the “refugee Site Location 2” page ? > > > Thank you for your participation > > Have a great day, > > Manon > > [image: CartONG- Humanitarian mapping and information management] > > Manon Viou > > Coordinatrice projet Missing Maps > > [image: Email:] m_v...@cartong.org | [image: Skype:] manon.viou > [image: Phone:] +33 (0)4 79 26 28 82 | [image: Mobile:] +33 (0)7 83889839 > > [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
Andrew, would you please repeat this analysis with all features tagged "protect_class=2" which have a wikidata tag? I suspect that many of those will not match according to Wikidata. On 4/6/20, Andrew Davidson wrote: > On 6/4/20 9:23 am, Joseph Eisenberg wrote: >> The only thing that the proposal page still needs is a couple more >> detailed definitions for some of the tags. > > Maybe not. A quick read finds this statement: > > protect_class=2 will be tagged as boundary=national_park (de facto) > > This is a problem because boundary=national_park already exists as a > generic tag for a conservation area. A quick survey of all of the > existing boundary=national_park with a wikidata link finds the following > range of IUCN Protected Area Categories: > > Class Count > IA 95 > IB 70 > II 848 > III 74 > IV 277 > V 234 > VI 159 > Total 1757 > > So less than 50% of "National Parks" are Cat II. > > I would suggest adding protection_class=national_park and dropping the > suggestion of using boundary=national_park. > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
On Mon, Apr 6, 2020 at 6:37 AM Andrew Davidson wrote: > > On 6/4/20 9:23 am, Joseph Eisenberg wrote: > > The only thing that the proposal page still needs is a couple more > > detailed definitions for some of the tags. > > Maybe not. A quick read finds this statement: > > protect_class=2 will be tagged as boundary=national_park (de facto) > > This is a problem because boundary=national_park already exists as a > generic tag for a conservation area. A quick survey of all of the > existing boundary=national_park with a wikidata link finds the following > range of IUCN Protected Area Categories: > > Class Count > IA 95 > IB 70 > II 848 > III 74 > IV 277 > V 234 > VI 159 > Total 1757 > > So less than 50% of "National Parks" are Cat II. > > I would suggest adding protection_class=national_park and dropping the > suggestion of using boundary=national_park. [A side point:] While I regard IUCN as a fine authority for the definition of the protection categories, I have found it to be considerably less useful for the application of the definition. For instance, in my home state of New York, all Wilderness Areas are tagged as category VI on IUCN's site. This is surely incorrect; the language that establishes them is nearly identical to the parallel language in the (US Federal) Wilderness Act. Motorized travel, harvesting of trees, bicycles, the erection of permanent structures (there is an exemption for certain improvements to trails and campsites to protect the rest of the area from hikers), all are strictly forbidden. Areas protected by NGO's (e.g., Nature Conservancy, Open Space Institute, Ducks Unlimited) and land trusts are not listed at all. [A stronger point:] I agree with you that boundary=national_park presents us with an awkward problem: what does it mean? It's a tag that's been around for a long time, and there are over a thousand objects that bear it. If it simply means that an area has the phrase, "National Park" (in the local language) somewhere in its name, it's pretty redundant, and fails to cover features that are national parks in structure and function but named differently. If it simply means 'category II protected area,' then it's surely redundant, but furthermore, half of the ones we have are mistagged. Perhaps most awkwardly, once we've chosen to use the tag, 'boundary=national_park', then 'boundary=protected_area' is no longer available to us. Can we work around the problem simply by allowing 'protection_class' to apply to 'boundary=national_park' as well as 'boundary=protected_area' and asserting that the default value of 'protection_class' for 'national_park' shall be assumed to be 2 (surely the plurality, if not the majority, of the areas listed above)? That could also allow us to choose, for example, 1b for a national park that is all wilderness, or 6 for one of the porous national parks in the UK, where most of the land is in private hands and people continue to live and work inside a park's borders (albeit under severe constraints as to the uses to which the land may be put). We could also then state that 'boundary=national_park' should be used in preference to 'boundary=protected_area' where it applies. That would also allow us to address Joseph Eisenberg's objection (in the talk page on the WIki) that the proposal violates the 'one object, one tag' principle. We could retain established tagging for such things as 'leisure=nature_reserve' or 'landuse=recreation_ground' while still indicating that the features enjoy a particular legal protection, by augmenting the tagging with a 'protection_class'. 'Boundary=protected_area' could then be reserved for the features for which no existing tagging applies. The inapplicability can come about for numerous reasons. For instance, 'protected_area' may become the unifying tag because the protection status is the only salient feature, or because there is no existing tagging that applies well, or because the area admits of mixed land uses that share a common boundary and name. -- 73 de ke9tv/2, Kevin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
I copied the draft note to a wiki page ... to facilitate the discussion regarding per key last update date meta data. https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap Best regards, Stuart On Mon, 6 Apr 2020 at 11:56, European Water Project < europeanwaterproj...@gmail.com> wrote: > Dear Martin, > > A date uses 3-4 bytes of memory. Just for brainstorming purposes, what > would be the total database size inflation if all keys on all nodes, ways > and relations in OpenStreetMap had 4 extra bytes of date meta data ? > > Best regards, > > Stuart > > On Mon, 6 Apr 2020 at 11:42, Martin Koppenhoefer > wrote: > >> Am Mo., 6. Apr. 2020 um 10:13 Uhr schrieb Frederik Ramm < >> frede...@remote.org>: >> >>> Secondly, this is a problem shared by all the "last survey" approaches: >>> You're standing the logic on its head. You're essentially saying: "If >>> the object has NOT changed in reality, please DO change it in OSM" (by >>> updating the last-checked tag). This means that we're being asked to >>> switch from mapping changes to mapping non-changes, with a potentially >>> huge data inflation in OSM (in theory I could update the "last survey" >>> of my local supermarket every time I shop there...). Your idea to >>> identify potentially fast-changing things and concentrate on these >>> softens the impact but still, we'd be churning out new versions of >>> objects like crazy just to confirm they are still there. (Everytime you >>> make a little change to one of the object's 10 tags, a full copy of the >>> object is created in OSM.) >>> >> >> >> I agree that the last survey date approach where "ordinary" tags are set, >> are crazy. On the other hand, it seems to be a topic that a significant >> number of contributors are interested in (currently ~710.000 tags for >> this). To do it better, maybe it could be stored in parallel? There is this >> long wish list for API 0.7 in the wiki ;-) >> https://wiki.openstreetmap.org/wiki/API_v0.7 >> Likely it would not be something to be implemented in the next 10 years >> or so, but at least it could be kept track of the idea and people could be >> pointed to it... >> >> There could be another table which stores for every tag on every object a >> confirmation date (by explicit request, i.e. it would only be set when a >> contributor explicitly sets it on a tag on an object, and when objects are >> split these would have to be split as well). This would imply that no new >> object version is created for simple property confirmations that do not >> alter the object. >> >> >> >> >>> >>> Thirdly, also shared by many "last survey" approaches: If you tag a >>> restaurant with a last survey date then exactly what have you surveyed? >>> Just that it is still there? That is still has these opening hours? Or >>> that it still gives you free water? There's potential from confusion >>> here. >> >> >> >> yes, the last survey confirmations would have to be stored on tag level, >> not on object level. >> >> Cheers >> Martin >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
It's true that not all "National Parks" are IUCN level 2, though most IUCN level 2 features appear to be National Parks, and of the 1700 boundary=national_park features which are also tagged with protect_class, 3/4 are protect_class=2, only 1 out of 4 has a different number. See http://overpass-turbo.eu/s/SsZ and http://overpass-turbo.eu/s/St0. The wiki page mentions that some other features, like Natural Monuments and Wilderness areas, are currently tagged as boundary=national_park, since that was the only original tag for such areas. So some features would need to be re-tagged as boundary=protected_area if we are going to use boundary=national_park for just National Parks, but this will be much less retagging than attempting to change all boundary=national_park features to =protected_area + the right IUCN category. If someone wants to directly tag the IUCN category for different areas, they could use a more specific tag like "iucn_cateogry=" with only the actual IUCN levels (1a, 1b, 2 - 6), though it seems like Wikidata might be a better place to record such details which have to be imported from outside datasets. https://en.wikipedia.org/wiki/IUCN_protected_area_categories -- Joseph Eisenberg On 4/6/20, Kevin Kenny wrote: > On Mon, Apr 6, 2020 at 6:37 AM Andrew Davidson wrote: >> >> On 6/4/20 9:23 am, Joseph Eisenberg wrote: >> > The only thing that the proposal page still needs is a couple more >> > detailed definitions for some of the tags. >> >> Maybe not. A quick read finds this statement: >> >> protect_class=2 will be tagged as boundary=national_park (de facto) >> >> This is a problem because boundary=national_park already exists as a >> generic tag for a conservation area. A quick survey of all of the >> existing boundary=national_park with a wikidata link finds the following >> range of IUCN Protected Area Categories: >> >> Class Count >> IA 95 >> IB 70 >> II 848 >> III 74 >> IV 277 >> V 234 >> VI 159 >> Total 1757 >> >> So less than 50% of "National Parks" are Cat II. >> >> I would suggest adding protection_class=national_park and dropping the >> suggestion of using boundary=national_park. > > [A side point:] > While I regard IUCN as a fine authority for the definition of the > protection categories, I have found it to be considerably less useful > for the application of the definition. For instance, in my home state > of New York, all Wilderness Areas are tagged as category VI on IUCN's > site. This is surely incorrect; the language that establishes them is > nearly identical to the parallel language in the (US Federal) > Wilderness Act. Motorized travel, harvesting of trees, bicycles, the > erection of permanent structures (there is an exemption for certain > improvements to trails and campsites to protect the rest of the area > from hikers), all are strictly forbidden. Areas protected by NGO's > (e.g., Nature Conservancy, Open Space Institute, Ducks Unlimited) and > land trusts are not listed at all. > > [A stronger point:] > I agree with you that boundary=national_park presents us with an > awkward problem: what does it mean? It's a tag that's been around for > a long time, and there are over a thousand objects that bear it. If it > simply means that an area has the phrase, "National Park" (in the > local language) somewhere in its name, it's pretty redundant, and > fails to cover features that are national parks in structure and > function but named differently. If it simply means 'category II > protected area,' then it's surely redundant, but furthermore, half of > the ones we have are mistagged. Perhaps most awkwardly, once we've > chosen to use the tag, 'boundary=national_park', then > 'boundary=protected_area' is no longer available to us. > > Can we work around the problem simply by allowing 'protection_class' > to apply to 'boundary=national_park' as well as > 'boundary=protected_area' and asserting that the default value of > 'protection_class' for 'national_park' shall be assumed to be 2 > (surely the plurality, if not the majority, of the areas listed > above)? That could also allow us to choose, for example, 1b for a > national park that is all wilderness, or 6 for one of the porous > national parks in the UK, where most of the land is in private hands > and people continue to live and work inside a park's borders (albeit > under severe constraints as to the uses to which the land may be put). > We could also then state that 'boundary=national_park' should be used > in preference to 'boundary=protected_area' where it applies. > > That would also allow us to address Joseph Eisenberg's objection (in > the talk page on the WIki) that the proposal violates the 'one object, > one tag' principle. We could retain established tagging for such > things as 'leisure=nature_reserve' or 'landuse=recreation_ground' > while still indicating that the features enjoy a particular legal > protection, by augmenting the tagging with a 'protection_class'.
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
Am Mo., 6. Apr. 2020 um 14:00 Uhr schrieb Kevin Kenny < kevin.b.ke...@gmail.com>: > That would also allow us to address Joseph Eisenberg's objection (in > the talk page on the WIki) that the proposal violates the 'one object, > one tag' principle. there is no such principle (AFAIK a principle like this is tried to adhere to in OSM-Carto, where they try that one tag is supported for displaying "one kind of thing" (and to which there is at least the exception of highway=footway and highway=path with foot=designated, etc.). But this isn't a general OSM principle (where we also generally try to avoid different tags with the same meaning, but accept their creation if there are reasons). The principle in OSM tagging is "One feature, one OSM element", and it will always work out if you apply the "correct interpretation", because the real world doesn't have "features", they come into existence with us defining what a feature is. E.g. a School delimited by a fence could be seen as 2 features: a school and a fence, or it could be seen as one feature, a fenced off school. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
On Mon, 6 Apr 2020 at 08:33, European Water Project < europeanwaterproj...@gmail.com> wrote: > > In order to maintain/improve the data quality for our mobile application, > I have been thinking about ways we can efficiently verify data for refill > points for drinking water at fountains participating refill cafes, bars and > other establishments. One idea I had was to create a map with possible > stale refill cafes (and rural fountains) for volunteers to verify. > > Please find attached a draft note for a feature proposal, which I have no > idea if is even technically possible, for automatically adding a last > verified date/creation date to specific keys. Maybe there is a better/more > efficient way ? > As others have pointed out, there are downsides to recording this in OSM. Others have also suggested the use of a parallel database. And I'd point out the additional burden of signing up to OSM/learning how to edit for ordinary data consumers who want to flag that some location has stopped providing free water. The best way to do this would be in your own app. Allow users to confirm they were able to get water or that the refill point is defunct. Record the data on your app's server against an ID you assign for each location.Come up with a tag for use in OSM that can be added to a refill point that gives a URL to check against your app's server's information, say drinking_water:ewp_id (and then wait for everyone to insist we don't have abbreviations in key values and that it should be drinking_water:european_water_project_id). It's going to need two QA packages. One to scan OSM for refill points and flag those that aren't in your own db. One to scan your own db for defunct refill points and flag to a human that they should be removed from OSM. Oh, and it's going to need a db at your end. :) -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hi Paul, Thank you for your comments. You may well be right in your analysis Recording a fountain out of order through the app is possible. I already count each fountain/refill cafe click per fountain in a server side mysql database (yes, I know osm numbers are mutable). . This being said, I do think it makes sense to have a generalize solution... not everyone will use our app for surveying water fountains globally ... and I am sure the issue of staleness is universal. For discussion purposes, it seems there are about 6.6 billion tag instances in the OpenStreetMap universe. If we decided to create a last updated meta data date for the year and month only (reducing to 2 Bytes) for 25% of the total tag universe, the uncompressed storage usage would be about 3GB or a 3% overhead. I think this overhead is worth considering. https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap Best regards, Stuart On Mon, 6 Apr 2020 at 15:11, Paul Allen wrote: > On Mon, 6 Apr 2020 at 08:33, European Water Project < > europeanwaterproj...@gmail.com> wrote: > >> >> In order to maintain/improve the data quality for our mobile application, >> I have been thinking about ways we can efficiently verify data for refill >> points for drinking water at fountains participating refill cafes, bars and >> other establishments. One idea I had was to create a map with possible >> stale refill cafes (and rural fountains) for volunteers to verify. >> >> Please find attached a draft note for a feature proposal, which I have no >> idea if is even technically possible, for automatically adding a last >> verified date/creation date to specific keys. Maybe there is a better/more >> efficient way ? >> > > As others have pointed out, there are downsides to recording this in OSM. > Others > have also suggested the use of a parallel database. And I'd point out the > additional burden of signing up to OSM/learning how to edit for ordinary > data consumers who want to flag that some location has stopped providing > free water. > > The best way to do this would be in your own app. Allow users to confirm > they > were able to get water or that the refill point is defunct. Record the > data on your > app's server against an ID you assign for each location.Come up with a > tag > for use in OSM that can be added to a refill point that gives a URL to > check > against your app's server's information, say drinking_water:ewp_id > (and then wait for everyone to insist we don't have abbreviations in key > values and that it should be drinking_water:european_water_project_id). > > It's going to need two QA packages. One to scan OSM for refill points and > flag those that aren't in your own db. One to scan your own db for defunct > refill points and flag to a human that they should be removed from OSM. > > Oh, and it's going to need a db at your end. :) > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Le 06.04.20 à 15:09, Paul Allen a écrit : > in your own app so every app 'll have it's own lascheck database ? so when I do my annual check-up of all the POIs in my comfort zone, It 'll need going into the different related quality monitoring applications them to mark that it's up to date so that several of us, on several applications, can use the work I've done ? on paper, the argument "do this in your own db" is easy, it allows not to have to think about the problems of outdated poi badly detectable in osm on a community level, it's the worst solution, much worse than adding an updated date on the small part of the 4 million shops=* that have been checked this year and that have not changed since f.e. last year, especially since there is often other information to be added during the annual audit, and in this case, metadata already got updated (even if too few tools are able to extract the date of last source=survey changeset for a poi, but this is another subject) > say drinking_water:ewp_id or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID or a wikidata, that's avoid the need for several external database to add their own id to the same object and if you still need a ref in osm, please don't use drinking_water:ewp_id but a key like ref:* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
On Mon, 6 Apr 2020 at 15:17, Marc M. wrote: > Le 06.04.20 à 15:09, Paul Allen a écrit : > > in your own app > > so every app 'll have it's own lascheck database ? > Those that want to know about last check dates. so when I do my annual check-up of all the POIs in my comfort zone, > It 'll need going into the different related quality monitoring > applications them to mark that it's up to date so that several of us, > on several applications, can use the work I've done ? > I'd hope QA tools would appear that can chase down refs. What do you do now? You go and look yourself. If an app exists that means you don't have to check some things, that's an advantage. Don't complain that there isn't an app for every POI you want to check. > > on paper, the argument "do this in your own db" is easy, > it allows not to have to think about the problems of outdated poi > badly detectable in osm > Yep. Because, as others have pointed out, implementing such a scheme in OSM is hard. Not just technically hard, but "overcoming all the people who insist OSM MUST NOT do this" hard. > > on a community level, it's the worst solution, It's certainly sub-optimal. But at least there is a chance of it happening because the decision to implement it rests upon a single person. This list will bun-fight over it for months, if not years, and nothing will come of it. > > say drinking_water:ewp_id > > or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID I didn't even know that existed. I'm not sure I trust such IDs to survive intensive editing by newbies who can delete an object then add it with quite different tags. > > or a wikidata, If a wikidata object exists. Given that I've mapped hamlets and villages around here that do not have wikidata objects, I doubt that every refill point will get one. that's avoid the need for several external database > to add their own id to the same object > That's sub-optimal, perhaps, but there's more chance of somebody who wrote a refill app giving all the refill points the app knows about an ID than them all appearing in wikidata. and if you still need a ref in osm, please don't use > drinking_water:ewp_id but a key like ref:* > Whatever. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hi Paul, Yep. Because, as others have pointed out, implementing such a scheme in OSM is hard. Not just technically hard, but "overcoming all the people who insist OSM MUST NOT do this" hard. Can we focus our discussions to the technical aspects of different solutions for storing key level last updated meta data date for the year and month? Unless we can develop a viable technical solution which has demonstrable benefits for data quality, the issue of being able to win over a large consensus of OSM users is moot. Best regards, Stuart On Mon, 6 Apr 2020 at 16:51, Paul Allen wrote: > On Mon, 6 Apr 2020 at 15:17, Marc M. wrote: > >> Le 06.04.20 à 15:09, Paul Allen a écrit : >> > in your own app >> >> so every app 'll have it's own lascheck database ? >> > > Those that want to know about last check dates. > > so when I do my annual check-up of all the POIs in my comfort zone, >> It 'll need going into the different related quality monitoring >> applications them to mark that it's up to date so that several of us, >> on several applications, can use the work I've done ? >> > > I'd hope QA tools would appear that can chase down refs. What do you > do now? You go and look yourself. If an app exists that means you > don't have to check some things, that's an advantage. Don't complain > that there isn't an app for every POI you want to check. > >> >> on paper, the argument "do this in your own db" is easy, >> it allows not to have to think about the problems of outdated poi >> badly detectable in osm >> > > Yep. Because, as others have pointed out, implementing such a scheme > in OSM is hard. Not just technically hard, but "overcoming all the people > who insist OSM MUST NOT do this" hard. > >> >> on a community level, it's the worst solution, > > > It's certainly sub-optimal. But at least there is a chance of it happening > because the decision to implement it rests upon a single person. This > list will bun-fight over it for months, if not years, and nothing will come > of it. > > >> > say drinking_water:ewp_id >> >> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID > > > I didn't even know that existed. I'm not sure I trust such IDs to survive > intensive editing by newbies who can delete an object then add it > with quite different tags. > >> >> or a wikidata, > > > If a wikidata object exists. Given that I've mapped hamlets and villages > around here that do not have wikidata objects, I doubt that every refill > point will get one. > > that's avoid the need for several external database >> to add their own id to the same object >> > > That's sub-optimal, perhaps, but there's more chance of somebody who > wrote a refill app giving all the refill points the app knows about an ID > than > them all appearing in wikidata. > > and if you still need a ref in osm, please don't use >> drinking_water:ewp_id but a key like ref:* >> > > Whatever. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
> one tag is supported for displaying "one kind of thing" That's not at all the same as "One feature, one OSM element". The basic principle is that you don't create 2 different database objects for the same thing: you don't map a single school as a node and as an area (closed way) around the node. Similarly, it's a good idea to add only one main feature tag to a database object. While some mappers like to save time by adding barrier=hedge to an amenity=school closed way, this makes it ambiguous: is the hedge an area or a line? If there is a name, is it the name of the hedge or the name of the school? A human can easily pick the right answer, but computers are not so good at this. -- Joseph Eisenberg On 4/6/20, Martin Koppenhoefer wrote: > Am Mo., 6. Apr. 2020 um 14:00 Uhr schrieb Kevin Kenny < > kevin.b.ke...@gmail.com>: > >> That would also allow us to address Joseph Eisenberg's objection (in >> the talk page on the WIki) that the proposal violates the 'one object, >> one tag' principle. > > > > there is no such principle (AFAIK a principle like this is tried to adhere > to in OSM-Carto, where they try that one tag is supported for displaying > "one kind of thing" (and to which there is at least the exception of > highway=footway and highway=path with foot=designated, etc.). But this > isn't a general OSM principle (where we also generally try to avoid > different tags with the same meaning, but accept their creation if there > are reasons). > The principle in OSM tagging is "One feature, one OSM element", and it will > always work out if you apply the "correct interpretation", because the real > world doesn't have "features", they come into existence with us defining > what a feature is. E.g. a School delimited by a fence could be seen as 2 > features: a school and a fence, or it could be seen as one feature, a > fenced off school. > > Cheers > Martin > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
On Mon, 6 Apr 2020 at 16:10, European Water Project < europeanwaterproj...@gmail.com> wrote: > > Yep. Because, as others have pointed out, implementing such a scheme > in OSM is hard. Not just technically hard, but "overcoming all the > people > who insist OSM MUST NOT do this" hard. > > Can we focus our discussions to the technical aspects of different > solutions for storing key level last updated meta data date for the year > and month? > This was already addressed by Frederick. It's technically hard. There have been many discussions over the years which have come to nothing because it's technically hard. He explained why it's technically hard. > Unless we can develop a viable technical solution which has demonstrable > benefits for data quality, the issue of being able to win over a large > consensus of OSM users is moot. > Some of those objecting are doing so because they've been round this loop several times before and concluded that it is technically hard. Others are objecting because it taints their idea about "purity" or some such. The fact is that the best reporting mechanism you have is people using your app to find a refill point then reporting it is closed. It's not just the best you have, it's the best you're going to have. Because people are unlikely to interact with your app once they have their water. Most will only ever interact to report a refill point is defunct and will do so because they're annoyed. Expecting mappers to wander around checking refill points is expecting far too much. Expecting people looking for refill points to tap a "this place still does refills" is expecting far too much. Any proposal that ignores how human beings operate is doomed to failure. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hi Paul, Maybe together we can come up with something new ... maybe not ... based on my admittedly limited knowledge of OpenStreetMap, the issue of stale data seems to be endemic for some types of data ... and not just a refill app issue. Adding a couple of extra bytes to the data structure for some tags on nodes, ways and relationships does not seem to be an impossible feat. I agree that user workflow is key and it is for that very reason that I believe that data quality maintenance must be crowd controlled by the most people possible. Key level last updated date meta data, might help this to be done more efficiently. The purpose of the note was to start a discussion. If there is consensus opposition to it ... that's fine too. Best regards, Stuart On Mon, 6 Apr 2020 at 17:26, Paul Allen wrote: > On Mon, 6 Apr 2020 at 16:10, European Water Project < > europeanwaterproj...@gmail.com> wrote: > >> >> Yep. Because, as others have pointed out, implementing such a scheme >> in OSM is hard. Not just technically hard, but "overcoming all the >> people >> who insist OSM MUST NOT do this" hard. >> >> Can we focus our discussions to the technical aspects of different >> solutions for storing key level last updated meta data date for the year >> and month? >> > > This was already addressed by Frederick. It's technically hard. There > have been > many discussions over the years which have come to nothing because it's > technically hard. He explained why it's technically hard. > > >> Unless we can develop a viable technical solution which has >> demonstrable benefits for data quality, the issue of being able to win over >> a large consensus of OSM users is moot. >> > > Some of those objecting are doing so because they've been round this loop > several times before and concluded that it is technically hard. Others > are objecting > because it taints their idea about "purity" or some such. > > The fact is that the best reporting mechanism you have is people using your > app to find a refill point then reporting it is closed. It's not just the > best you > have, it's the best you're going to have. Because people are unlikely to > interact with your app once they have their water. Most will only ever > interact to report a refill point is defunct and will do so because they're > annoyed. Expecting mappers to wander around checking refill points > is expecting far too much. Expecting people looking for refill points > to tap a "this place still does refills" is expecting far too much. > > Any proposal that ignores how human beings operate is doomed to > failure. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
For the record (though I understand that English track meaning doesn't fit well) leisure=track can be used with highway=*, 5% of them highway=path wiki page says : «This includes walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails as well as combinations of the above. [...] Intended uses can be indicated with the various access keys; e.g., bicycle=designated and foot=designated.» So I understand that for mtb trail path should be preferred. IMBA have a book of how to make a good mtb trail, enjoy :) https://www.imba.com/sites/default/files/GQTE_Digital_Book_Rev_6.11.18_high_res.pdf I can understand from videos that features can be : jump, wood bridges, high U turn, skinny board path, high stone, etc (those features could be map) mtb trail can be wider than a path, like track, so the tag to say that a way is designed for mtb should be able to be used on any highway (hence path=mtb is may be not the good one). So to sum up my current position is : If a path is signed to be usable by mtb we can tag mtb=designated If a path can only be used by mtb I think access=no mtb=designated can be used (I understand that goes against path multi usage definition, but why access tags exist if we cannot use it ?) So the last thing we need is : how to tag a path made with mtb features - tag every feature, keys need to be created (may be not this time :) - tag the way with one key like path=mtb, but as said this is not great for track may be we can use trail=mtb ? I don't know if other kind of trail (horse, hiking) can have also specific features for their enjoyment. (It seems : log, river, steps, climbing, rope...) Le lun. 6 avr. 2020 à 08:52, Andrew Harvey a écrit : > On Mon, 6 Apr 2020 at 03:27, Adam Franco wrote: > >> Thank you for putting together this highway=path + path=mtb suggestion, >> Andrew. This is first suggestion on this thread that has felt like a good >> direction forward. First and foremost, mountain bike trails are paths, >> anything further is a qualifier that adds precision, but not a >> contradiction. >> >> In contrast, proposals to change to leisure=track feel wrong because >> these are routable ways and dropping highway=* removes them from the >> routable network. >> > > In theory you could still include leisure=track in your routable network, > but it needs more fine tuning hence less likely "out of the box" and isn't > ideal in my opinion. > > >> Similarly, fiddling with access tags to imply mountain-biking trails >> feels like adding too much inference and dual-purpose to these tags that >> then complicate the access scheme. In general, I think expanding the >> path=* key would be a good way to add additional precision for other >> "special purpose" paths. >> > >> I'm a long-time mountain biker and also a bicycle commuter, so I can >> sympathize with both camps. While my area (Vermont, USA) has some >> special-purpose mountain-bike trails (with ramps and the like) that are >> built at ski areas, most of our trails are built and cut by and for >> mountain bikers, but are also used by trail-runners and walkers. The "built >> for mountain bikers" part means that they have been sculpted to follow the >> terrain in a way that is fun on a mountain bike, with turn radii and grades >> that allow a flowing cadence. Often elevation gains/drops are managed to >> optimize for time coasting downhill, rather than dropping steeper than is >> needed only to have to climb again. These trails are also usually great for >> hiking/running, but also feel great on a bike. In contrast, a trail "built >> for hiking" might not worry about twisting between some large jumbled rocks >> that tires simply can't traverse, or might use steep, straight grades and >> stairs that "waste" elevation gains in a way that is less-fun on wheels. >> Long story short the vast majority of specialized mountain-bike trails >> *are* highway=path, they are just a particular flavor of highway=path. >> >> I would strongly support a formalized proposal based on what you put >> together. >> > > Good to hear that feedback In my proposal I'm agnostic to built/maintains > it, and agnostic to if it's officially sanctioned or not, so path=mtb would > be based on how it's built/who it's built for. > > On Mon, 6 Apr 2020 at 04:50, Volker Schmidt wrote: > >> It sounds as we have not yet made clear the difference between MTB routes >> and MTB leisure tracks. The former are routes that are suitable for >> mountain bikers, but they are on ways shared with other users, whereas the >> latter are for the exclusive use with MTBs - no other user is admitted. >> That is a similar distinction as between a road and a motor racing track. > > > A MTB route is just a relation with type=route + route=mtb, usually a > signposted collection of smaller track segments, it could go over other > track types like highway=track and or designated mountain bike trails (as > proposed highway=path + path=mtb). > > On Mon, 6 Apr 20
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hi, On 06.04.20 17:25, Paul Allen wrote: > Expecting mappers to wander around checking refill points > is expecting far too much. Expecting people looking for refill points > to tap a "this place still does refills" is expecting far too much. Only way I would see this working is a "gamification" thing where - a bit like the "Kort game" of days past (https://wiki.openstreetmap.org/wiki/Kort_Game) and a bit like "StreetComplete" - people who happen to be in a specific location and who have signed up to the game/system are nudged to go check something - "hey since you're standing in front of restaurant X, please check if it still has the property Y". But that would require people to sign up, and of course a server-side application to track contributions, leaderboards and so on. Whether or not the back-end storage is then OpenStreetMap or a separate database is actually a smaller question. Simply establishing a tag and hoping that you have to develop and run neither a backend (because OSM will do it) nor a frontend (because people can use Vespucci) is extremely optimistic. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
I don't think we want or need an mtb= tag. Even though we don't need a path=mtb tag, I'd be OK with it. It would be a shortcut instead of adding some of the other tags. I don't think routers for cycle touring should rely on this though. I live in a popular mtb location (Colorado, USA), and I don't think I've come across an mtb=* way. My tag searching skills are weak, but on taginfo it looks like very few instances of this tag in the rocky mtns, quite a few in Europe. On 4/5/20 3:52 AM, Andrew Harvey wrote: I agree with Martin here, if tags are used but not documented on the wiki, discussion on the mailing lists or through a proposal process, how would such tags hold any meaning? Different editors probably add it to mean different things. We can't really make any assumptions about what they mean, which is why this whole discussion exists so we can have some kind of contract between people entering tags and people consuming data, so we have a shared understanding of the meaning of those tags. Anyone who's used the mtb= tags so far, it would be great to hear what this was meant to mean. On Sun, 5 Apr 2020 at 19:08, Martin Koppenhoefer mailto:dieterdre...@gmail.com>> wrote: Am So., 5. Apr. 2020 um 11:03 Uhr schrieb Yves mailto:yve...@mailbox.org>>: As a side note: I would be worried to redefine the mtb=yes/no tag that is not documented but widely used. how can it be "redefined" if there isn't documentation about it? Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Hi Frederik, I agree 100%. The proposal thesis is that "Key level last updated date meta data" within OSM, might be a useful ingredient for facilitating better data quality maintenance on data which tends to go stale. Best regards, Stuart On Mon, 6 Apr 2020 at 18:24, Frederik Ramm wrote: > Hi, > > On 06.04.20 17:25, Paul Allen wrote: > > Expecting mappers to wander around checking refill points > > is expecting far too much. Expecting people looking for refill points > > to tap a "this place still does refills" is expecting far too much. > > Only way I would see this working is a "gamification" thing where - a > bit like the "Kort game" of days past > (https://wiki.openstreetmap.org/wiki/Kort_Game) and a bit like > "StreetComplete" - people who happen to be in a specific location and > who have signed up to the game/system are nudged to go check something - > "hey since you're standing in front of restaurant X, please check if it > still has the property Y". But that would require people to sign up, and > of course a server-side application to track contributions, leaderboards > and so on. Whether or not the back-end storage is then OpenStreetMap or > a separate database is actually a smaller question. > > Simply establishing a tag and hoping that you have to develop and run > neither a backend (because OSM will do it) nor a frontend (because > people can use Vespucci) is extremely optimistic. > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Urgent Care
the wording is one issue but I was more interested in meaning. is it the same meaning ? if not please explain the difference telling me "tag as you wis" is not an interesting answer for the quality Le 06.04.20 à 13:11, Ty S a écrit : > Honestly, reservation is definitely the wrong wording here, and so is > emergency (see talk page of proposal) however, tag as you wish. > > *From:* Marc M. > *Sent:* Monday, April 6, 2020 2:27 AM > *To:* tagging@openstreetmap.org > *Subject:* Re: [Tagging] Feature Proposal - RFC - Urgent Care > > Le 05.04.20 à 17:06, Ty Stockman a écrit : >> https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care >> The urgent care tag is used at, for example, clinics, that offer walk-in >> service > > isn't "walk-in" already included in reservation=no ? > and/or with emergency=yes ? > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Can highway=cycleway be limited to MTB?
Le 06.04.20 à 18:13, Florimond Berthoux a écrit : > If a path can only be used by mtb I think access=no mtb=designated can > be used (I understand that goes against path multi usage definition, > but why access tags exist if we cannot use it ?) I never see sutch sign. but if it exist, why not. but imho it only exist in leisure=track sport=mtb area so why tag it as a path ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Le 06.04.20 à 18:23, Frederik Ramm a écrit : > Only way I would see this working is a "gamification" thing QA tools can also warn "this poi hasn't been changed in a long time, maybe you wish to review/resurvey it" Some ppl like to have an "up-to-date area", and not rely on luck to systematically detect obsolete things ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)
On 6/4/20 9:59 pm, Kevin Kenny wrote: Can we work around the problem simply by allowing 'protection_class' to apply to 'boundary=national_park' as well as 'boundary=protected_area' and asserting that the default value of 'protection_class' for 'national_park' shall be assumed to be 2 (surely the plurality, if not the majority, of the areas listed above)? Currently there are two ways to tag a conservation area: boundary=national_park or boundary=protected_area protect_class=1 to 7 The first is generic, the second is specific as to what level of conservation an area has. I would have assumed that if you were proposing to replace the class numbers with phrases then you'd just create a phrase for class 2, rather than trying to redefine an existing tag. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
sent from a phone > On 6. Apr 2020, at 16:51, Paul Allen wrote: > >> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID > > I didn't even know that existed. I'm not sure I trust such IDs to survive > intensive editing by newbies who can delete an object then add it > with quite different tags. these IDs are defined through their significant properties, if these get “messed up” you may hope that someone else will fix it sooner or later. Compared to this, an ID_mySpecial_App=123 tag has much more potential for breakage, because following editors don’t know what it refers to (e.g. the physical place or the business/service?), and often don’t know how to deal with it when some properties have changed, or when they split them: keep it on all parts, some parts or remove it? To solve this you’d have to know what mySpecialApp does and how it uses the IDs. And we’d end up with a lot of different opaque foreign keys cluttering up the same objects, in some cases, even if we required the linked db to be free and open. On the other hand there are already people adding references to proprietary databases, e.g. 8 facebook urls, 2000 google ids, 500 foursquare. The trick is to offer message relaying and use a contact: tag ;-) Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap
Dear Martin, Yes, using external tables unioned to objects by opaque keys is not a very KISS solution. A more KISS solution would be to keep tag meta data close to or even better within the element itself. Assuming all tag values are stored in zero based arrays, could we not add a 2 byte last updated/creation date meta data value to the [-1] index. The overhead would be minimal, the overall OSM data structure would not have to be modified. Best regards, Stuart On Tue, 7 Apr 2020 at 01:30, Martin Koppenhoefer wrote: > > > sent from a phone > > On 6. Apr 2020, at 16:51, Paul Allen wrote: > > or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID > > > I didn't even know that existed. I'm not sure I trust such IDs to survive > intensive editing by newbies who can delete an object then add it > with quite different tags. > > > > these IDs are defined through their significant properties, if these get > “messed up” you may hope that someone else will fix it sooner or later. > > Compared to this, an ID_mySpecial_App=123 tag has much more potential for > breakage, because following editors don’t know what it refers to (e.g. the > physical place or the business/service?), and often don’t know how to deal > with it when some properties have changed, or when they split them: keep it > on all parts, some parts or remove it? To solve this you’d have to know > what mySpecialApp does and how it uses the IDs. > > And we’d end up with a lot of different opaque foreign keys cluttering up > the same objects, in some cases, even if we required the linked db to be > free and open. > On the other hand there are already people adding references to > proprietary databases, e.g. 8 facebook urls, 2000 google ids, 500 > foursquare. The trick is to offer message relaying and use a contact: tag > ;-) > > Cheers Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
