Re: [Tagging] Feature Proposal - RFC - highway=scramble
Dear all, Hungerburg wrote Mon Sep 26 2022 22:19:03 GMT+0200 Nearly two weeks passed since the RfC started. Quite some changes have happened. I’d like to invite a second reading, to help weed out remaining problems. https://wiki.openstreetmap.org/wiki/Proposed_features/highway=scramble "use of hands is required" is not defined at all, thus stays fully subjective: My sister needs hands where I do not even start to think about using hands, most people living in German cities will use hands where people from rural areas of Peru's Andes won't because their daily routine ways differ so much. → This massively reduces the added value of highway=scramble and invites for edit wars. I posted some definition possibilities in my mail of 2022-09-20, 17:00 scramble=grade* is mentioned in the current proposal. The grades definition posted earlier in this thread tells On grade 2 and 3 scrambles it’s worthwhile taking a rope at least 30m long, some eight-foot slings, HMS karabiners and maybe a very small rack, half a dozen large nuts and hexes at most. The proposal excludes any scrambles using equipment, so forbids all scrambles of grades 2+3 to be tagged as highway=scramble. Thus, only scramble=grade1 remains by definition, so it cannot add any information and shall be removed from the proposal. Regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are different definitions for same key/value OK? – was: Re: Is tracktype=grade1 surface=compacted a valid combination?
On Sep 26, 2022, at 5:14 PM, Georg wrote: > Dear all, > stevea wrote Mon Sep 26 2022 01:36:26 GMT+0200 > Is tracktype=grade1 surface=compacted a valid combination? >>> >>> while the EN wiki page https://wiki.openstreetmap.org/wiki/Key:tracktype >>> does not explicitly exclude it [...] the DE wiki page >> >>> https://wiki.openstreetmap.org/wiki/DE:Key:tracktype tells (translated >>> by me) "waterproof surface" and thus explicitly excludes the combination. > >> As I said earlier, and as I've found in OSM across different countries / >> continents, there do seem to be and will seem to be "regional variations" >> like this. The wiki using words like "usually" might encourage this, but it >> also "encompasses" it, as we're not very likely to get "perfection" with >> tracktype=* grades across the whole world. Best practice seems to be >> denoting this in our respective wikis, which we appear to be on track doing >> so now. > > noting regional or language specific variances of a definition in the > wiki is OK for manual mapping, but (and wrote a great deal more, which I appreciate, have read and here politely redact most of it). > > Hence, I speak up for and strongly prefer to limit variances of > definitions as much as possible, e.g. where simply not at all applicable > because of local law. > > How do you see it? The short version of how I see it is "there will be regional variations" and "updating what regions know and do about this in our wiki is at least something (a good start, anyway)." I'm certainly open and very much in a listening mode to hear how others think we might address the specifics of this (and related tags where similar "syntactic smearing" takes place due to regional differences). I also believe that acknowledging that "we are not likely to achieve perfection" and "perfection is the enemy of the good" are useful talking points for us to agree upon. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Are different definitions for same key/value OK? – was: Re: Is tracktype=grade1 surface=compacted a valid combination?
Dear all, stevea wrote Mon Sep 26 2022 01:36:26 GMT+0200 Is tracktype=grade1 surface=compacted a valid combination? while the EN wiki page https://wiki.openstreetmap.org/wiki/Key:tracktype does not explicitly exclude it [...] the DE wiki page >> https://wiki.openstreetmap.org/wiki/DE:Key:tracktype tells (translated by me) "waterproof surface" and thus explicitly excludes the combination. As I said earlier, and as I've found in OSM across different countries / continents, there do seem to be and will seem to be "regional variations" like this. The wiki using words like "usually" might encourage this, but it also "encompasses" it, as we're not very likely to get "perfection" with tracktype=* grades across the whole world. Best practice seems to be denoting this in our respective wikis, which we appear to be on track doing so now. noting regional or language specific variances of a definition in the wiki is OK for manual mapping, but 1) causes quite a lot of wiki maintenance effort: Every language needs to contain all variances of all other languages because we can't expect e.g. all US citizens to understand French, German and Italian sufficiently well when they are touring Europe and driving the 3 hours from Euro-Airport (in France) through German speaking part of Switzerland to Italy. 2) makes it quite hard to create programs that work correctly and behave user friendly. Example below. 3) discussions are much more prone to misunderstandings if the same key/value is defined in different ways, like we recently saw for SAC scale in scramble topic (may or must a T5 path contain scramble sections?). 4) because we simply don't have the resources to implement 1+2 really 100%, we end up with data that does not match one of the definitions. And cleanup is really difficult, because you cannot tell which data was entered due to which definition. Example below. Example for 2): A seasoned US mapper travels central Europe and maps there using Vespucci. The mapper's mobile is still in English, so Vespucci cannot simply rely on "it's enough if German GUI covers German variance". Instead, it would now have to contain a piece of logic telling that temporarily, the English preset texts need to be changed to match German content (so all regional variations need to be existing in all preset languages). Moreover, the mapper shall be made aware of this switch, because a seasoned mapper won't read the texts all the time but instead directly click on a value out of routine. Things get worse if the mapper has still pending changes in US and jumps between changes in DE and US, as Vespucci needs to switch presets depending on which edit is shown to the user. Same applies to all other editors, all quality assurance tools, all routers, many analysis tools,... Example for 4): A highway=path is tagged as SAC T5. Does it contain a scrambling section as required by SAC, or does it not, because the EN variant of https://wiki.openstreetmap.org/wiki/Key:sac_scale did mention for years that scrambling is optional for T5, so someone may have tagged the path as T5 despite it does not contain a scrambling section, i.e. it shall be tagged as T4 only. As a consequence, we'd need to re-check the tagging for thousands of paths but we have AFAIK no effective means to document which paths have been checked (e.g. MapRoulette does not help much here). Hence, I speak up for and strongly prefer to limit variances of definitions as much as possible, e.g. where simply not at all applicable because of local law. How do you see it? Best regards, Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - pickup
Many retailers let you order online and pick up what you ordered at a store (this is often called click and collect). However such retailers also often provide dedicated pick up points — these are not stores — you cannot buy anything there, you can only pick up products there that you previously ordered online. Currently such pickup locations are tagged with shop=outpost, which does not make any sense. A pickup location is neither a shop (because you cannot buy anything there) nor an outpost (which is a military post or an outlying settlement). So why should it be tagged with shop=outpost? That is just confusing and misleading. I therefore propose to deprecate shop=outpost in favor of pickup=*. E.g. an IKEA pickup point could be tagged with pickup=furniture and a Decathlon pickup point with pickup=sports (the values of pickup=* are meant to be analogous to the already established shop=* values). https://wiki.openstreetmap.org/wiki/Proposal:Pickup Please discuss this proposal on its Wiki Talk page. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Training
Maybe also amenity=university, but this out of scope of this proposal. вт, 27 сент. 2022 г., 1:27 Graeme Fitzpatrick : > > On Tue, 27 Sept 2022 at 02:10, Mateusz Konieczny via Tagging < > tagging@openstreetmap.org> wrote: > >> >> What about universities where future sailors/pilots are training >> (often these are military schools). >> > > They should then be under military=base + base_function=training > > Thanks > > Graeme > > ___ > 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 - Training
On Tue, 27 Sept 2022 at 02:10, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > > What about universities where future sailors/pilots are training > (often these are military schools). > They should then be under military=base + base_function=training Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Nearly two weeks passed since the RfC started. Quite some changes have happened. I’d like to invite a second reading, to help weed out remaining problems. https://wiki.openstreetmap.org/wiki/Proposed_features/highway=scramble Please comment in the medium of your choice. Thank you in advance ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - highway=scramble
Thank you Alan for the insightful comment. The scrambles I have in mind require little to no generalization step. This is the concept that I was missing to understand some previous comments. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Training
Probably worth mentioning how places which are officially classified as schools and part of school system would be affected. What about for example https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dmusic_school ? What about universities where future sailors/pilots are training (often these are military schools). Sep 26, 2022, 15:01 by illiamarchenk...@gmail.com: > Training centers (reactivated proposal). > https://wiki.openstreetmap.org/wiki/Proposed_features/training > Please discuss this proposal on its Wiki Talk page. > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] incline=up_and_down
Though note that for areas without very good DEM this tags may still provide useful info on short section of way. There is a difference between gradual drop with a normal slope and case where you have bunch of 10 cm high cliffs/kerbs - especially when going uphill. Or 2m long section which is strongly uphill within slope which is normal otherwise. Sep 26, 2022, 14:40 by bradha...@fastmail.com: > > Any good cycling router needs to use a digital elevation model in it's > algorithm, or use elevation tied to the paths somehow (such as with a > gpx track). These odd OSM tags are a sideshow. > > > > > On 9/26/22 03:16, Mateusz Konieczny via Tagging wrote: > >> >> >> >> 26 wrz 2022, 09:02 od >> o...@tobias-knerr.de>> : >> >>> On 26.09.22 02:21 Mateusz Konieczny wrote: >>> But what can be done in cases where there is no realincline but path goes through series of up and down hops? >>> >>> I would intuitively prefer if you put the information about the >>> presence of "hops" into a specialized tag instead of making the >>> value space of an established and approved key more messy. >>> >>> Leave incline=* to describe the overall incline of the way in that >>> case. That is: Do you end up lower or higher than you were in the >>> start? >>> >> In this case I am thinking about something >> that overall has tiny elevation change. >> >> What would you propose as such extra tag? >> >> up_and_down=yes >> >> (not really happy about it, but right now I >> have no better idea)? >> >> ___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] Feature Proposal - RFC - Training
Training centers (reactivated proposal). https://wiki.openstreetmap.org/wiki/Proposed_features/training Please discuss this proposal on its Wiki Talk page. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] incline=up_and_down
To me, it seems that the root of the problem is that the mtb:scale:uphill=* key is flawed. Instead, these keys should be name mtb:scale:forward=* and mtb:scale:backward=* . This would make everything unambiguous. And, of course, an additional incline=up/down would be optional but very helpful. One could for example easily infer a mtb:scale:uphill/downhill from this combination (if still of interest for some reason). (+obvious other advantages for routing) On 26/09/2022 14:40, Brad Haack wrote: Any good cycling router needs to use a digital elevation model in it's algorithm, or use elevation tied to the paths somehow (such as with a gpx track). These odd OSM tags are a sideshow. On 9/26/22 03:16, Mateusz Konieczny via Tagging wrote: 26 wrz 2022, 09:02 od o...@tobias-knerr.de: On 26.09.22 02:21 Mateusz Konieczny wrote: But what can be done in cases where there is no real incline but path goes through series of up and down hops? I would intuitively prefer if you put the information about the presence of "hops" into a specialized tag instead of making the value space of an established and approved key more messy. Leave incline=* to describe the overall incline of the way in that case. That is: Do you end up lower or higher than you were in the start? In this case I am thinking about something that overall has tiny elevation change. What would you propose as such extra tag? up_and_down=yes (not really happy about it, but right now I have no better idea)? ___ 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] incline=up_and_down
Any good cycling router needs to use a digital elevation model in it's algorithm, or use elevation tied to the paths somehow (such as with a gpx track). These odd OSM tags are a sideshow. On 9/26/22 03:16, Mateusz Konieczny via Tagging wrote: 26 wrz 2022, 09:02 od o...@tobias-knerr.de: On 26.09.22 02:21 Mateusz Konieczny wrote: But what can be done in cases where there is no real incline but path goes through series of up and down hops? I would intuitively prefer if you put the information about the presence of "hops" into a specialized tag instead of making the value space of an established and approved key more messy. Leave incline=* to describe the overall incline of the way in that case. That is: Do you end up lower or higher than you were in the start? In this case I am thinking about something that overall has tiny elevation change. What would you propose as such extra tag? up_and_down=yes (not really happy about it, but right now I have no better idea)? ___ 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] incline=up_and_down
Still, splitting into 60 segments withinaccuracy greater than their lengthseems to not be a good idea. 26 wrz 2022, 07:09 od y...@mailbox.org: > You can't really micromap until you micromap for real ;-) > More seriously, there may be no need to split ways down to the *exact* meter > to give the router a sense of the way profile with incline=*. > Yves > > Le 26 septembre 2022 02:21:24 GMT+02:00, Mateusz Konieczny via Tagging > a écrit : > >> tagging incline direction on ways with mtb:scale:uphill is useful >> as otherwise you need high-quality elevation model >> to do routing, and in some cases it may be unavailable at all in sufficient >> detail >> >> >> >> I wanted to systematically tag mtb scale info in some places to improve >> routing >> for bicycle trekking. >> >> Some people (like myself) are NOT interested at all in MTB routes but >> mtb:scale=1 >> (or just mtb:scale=0) is still fine for them. >> >> >> >> >> >> >> So mtb:scale=1 mtb:scale:uphill=3 is fine downhill but not uphill for such >> people, >> but it is hard to check in which way given path goes uphill >> >> >> >> >> This is also recommended by wiki: >> >> https://wiki.openstreetmap.org/w/index.php?title=Key:mtb:scale=en#mtb:scale:uphill=0-5 >> >> So I wanted to systematically tag missing incline tags, as even without exact >> value it is already valuable info for routing. >> >> But what can be done in cases where there is no real incline but >> path goes through series of up and down hops? >> >> In many cases it is deliberately engineered (legally or not) >> and looks often like >> https://www.moredirt.com/photo/91766 >> https://www.zip06.com/local-news/20220622/rockland-preserve-pump-track-is-officially-a-hit/>> >> >> https://www.bikehinton.com/hinton-bike-park >> - >> >> Would it be fine to tag incline=up_and_down in such case? >> https://taginfo.openstreetmap.org/tags/incline=up_and_down >> has some minimal use already. >> >> Or maybe incline:variable=yes? >> >> Splitting such way into incline=up / incline=down segments >> is too much for me and I was splitting footway into 20m >> segments to mark changing surface/lit status. >> >> - >> >> And why I want to tag some incline value? Because I want to do it >> systematically for all such ways. >> See >> https://github.com/streetcomplete/StreetComplete/pull/4385 >> for the context (I want to also add it to StreetComplete if it will >> be accepted there). >>___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] incline=up_and_down
26 wrz 2022, 09:02 od o...@tobias-knerr.de: > On 26.09.22 02:21 Mateusz Konieczny wrote: > >> But what can be done in cases where there is no real incline but >> path goes through series of up and down hops? >> > > I would intuitively prefer if you put the information about the presence of > "hops" into a specialized tag instead of making the value space of an > established and approved key more messy. > > Leave incline=* to describe the overall incline of the way in that case. That > is: Do you end up lower or higher than you were in the start? > In this case I am thinking about somethingthat overall has tiny elevation change. What would you propose as such extra tag? up_and_down=yes (not really happy about it, but right now Ihave no better idea)?___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] incline=up_and_down
On 26.09.22 02:21 Mateusz Konieczny wrote: But what can be done in cases where there is no real incline but path goes through series of up and down hops? I would intuitively prefer if you put the information about the presence of "hops" into a specialized tag instead of making the value space of an established and approved key more messy. Leave incline=* to describe the overall incline of the way in that case. That is: Do you end up lower or higher than you were in the start? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
