Re: [Tagging] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc
The landcover key covers this nicely. For hedge barrier areas, tag barrier=hedge for the perimeter, then landcover=hedge to indicate the hedge covers the area (do not land a balloon there and don't plan to walk through it). The combined information is then exactly the same as barrier=hedge, area=yes, which is the established tagging. Fr gr Peter Elderson Op zo 9 feb. 2020 om 03:35 schreef Joseph Eisenberg < joseph.eisenb...@gmail.com>: > In the discussion about `barrier=hedge` areas, it is clear that > mappers want a way to tag small areas of bushes and shrubs, and not > everyone is happy about using natural=scrub for this case. > > Currently there is a tag landuse=grass for small areas of managed > grass, but this might be considered to exclude other non-woody herbs. > And leisure=garden is usually considered the whole area of a garden, > rather than being limited to a certain type of vegetation. > > I would suggest that we need a more developed system of tags for > micro-mapping small areas of plants, not just woody-stemmed bushes and > shrubs, but also semi-annuals, herbaceous perenials (e.g. in the > tropics) and annual flowers and herbs. > > This would also help with problems like using village_green for all > sorts of areas: see discussions and examples in > https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dvillage_green > > Rather than just discussing how the tag small areas of bushes or > hedges, how about how to tag this area of flowers: > https://wiki.openstreetmap.org/wiki/File:Vg6.jpg > > Or a garden bed planted with these: > https://www.thaigardendesign.com/bird-of-paradise-strelitzia/ - or > these: > https://www.wikilawn.com/flowers/ornamental-red-ginger-plant-alpinia-purpurata/ > > Or this bed full of succulent plants, in a semi-arid region: > > https://www.finegardening.com/app/uploads/sites/finegardening.com/files/images/spotlight-collection/resize_of_pa230150.jpg > > Are people micro-mapping areas such as these? > > How specific should the tagging be? > > - Joseph Eisenberg > > ___ > 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] [OSM-talk] OpenStreetMap Carto release v4.25.0
Mateusz Konieczny via Tagging : > If you think that there is broad support for landcover proposal - feel > free to > start vote on the landcover proposal. > How about changing established tagging for hedge areas - was there a proposal? What did it propose? I must have missed it somehow. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] barrier=hedge
Well, I'm not so good with overpass turbo, but this query gives an
impression:
[out:json][timeout:25];
(
way["barrier"="hedge"]["area"="yes"]({{bbox}});
);
// print results
out body;
>;
out skel qt;
When I run it on different parts of Nederland and Belgium, it finds many
hedge areas in most parts. Zeeland, not so much.
Data inspection shows these are almost all intentionally mapped hedge
areas. Not leisure/natural/landuse etc.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0
Christoph Hormann : > On Friday 07 February 2020, Peter Elderson wrote: > > E.g. if a solution would be to tag hedge areas as natural=hedge > > or landcover=hedge, then the change path would be for the renderer to > > temporarily render the old AND the new tagging, so mappers can edit > > the old tagging to the new tagging. > > We always try to avoid that because it never works towards a more > consistent tagging but only perpetualizes the use of both tags as > synonyms because mappers get feedback that both tags are correct. > Not if a clear path is agreed upon and an end date is set, communicated and documented. Most OSM communities wil handle his in time. Basic change management, this. > ___ > 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] [OSM-talk] OpenStreetMap Carto release v4.25.0
Christoph Hormann : > I originally was under the impression that > use of barrier tags as a secondary tag for landuse polygons etc. was > consensus among mappers based on the fairly large use numbers for that > (>350k) Correct. > but it quite clearly isn't. Yes it is, but an explicit area=yes adds the information that the whole area is the barrier. If area=yes is added to say a leisure area surrounded by a hedge, that is a mapping mistake. If that results in the area displaying as a hedge area, the mapper has to correct that, not the renderer. ___ > 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] [OSM-talk] OpenStreetMap Carto release v4.25.0
oseph Eisenberg : > 2) Many hedges which were mapped like areas are currently missing > `area=yes` tags. In this comment > ( > https://github.com/gravitystorm/openstreetmap-carto/pull/3844#issuecomment-582692389 > ) > you can see that over 90% of the `barrier=hedge` closed ways in a > Dutch province (random example) are missing `area=yes`, though they > appear to be mapping the outline/area of the hedge. This means that a > rendering solution that relies on `area=yes` would miss a large > percentage of hedges mapped in this way. The situation is worse for > barrier=wall. Zeeland is a bad example, and absolute numbers are low. Not wise to base decisions on that. Please check Noord-Brabant, Zuid-Holland, Utrecht. Nederland as a whole did not have any problem with the wiki-conform rendering, but it does have a huge problem with the current rendering which does not conform to the wiki. If mappers do not conform to the wiki documentation, the tagging is the error, and it is a good thing that that is visible, so mappers will correct the mapping. I agree that tagging could have been better defined. I am not against simpler/cleaner/better tagging, if it helps renderers. The first thing to do is to get the problem clear so that mappers can agree to find a better solution. Then discuss solutions, including a change path. E.g. if a solution would be to tag hedge areas as natural=hedge or landcover=hedge, then the change path would be for the renderer to temporarily render the old AND the new tagging, so mappers can edit the old tagging to the new tagging. Then set an end of support date for the old tagging. Would that be so hard? > > ___ > 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] [OSM-talk] OpenStreetMap Carto release v4.25.0
Joseph Eisenberg : > The Netherlands has been claimed as a place where barrier=hedge areas > are used properly and are necessary. I have already downloaded one > whole provicne, Zeeland, which has quite complete landcover and > landuse mapping due to an import. In Zeeland there are 149 uses of > `barrier=hedge` on a closed way without `area=yes` or landuse=, > natural= or leisure=, and only 12 closed ways with `barrier=hedge` + > `area=yes`. > Zeeland, of all places... Most of Zeeland is water, dykes and polders. Try Noord-Brabant, Zuid-Holland, Utrecht. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0
+1 Mvg Peter Elderson > Op 5 feb. 2020 om 16:37 heeft Jeroen Hoek het volgende > geschreven: > > On 05-02-2020 16:10, Paul Allen wrote: >> 4) Where the only tags are barrier=hedge + area=yes then render >> as before, a hedge that has area. > > There are some additional tags that should be allowed for. Including > (mainly?) `height=*`. > >> 5) Introduce, and render, landcover=hedge so we can tag an object >> as landcover=hedge + barrier=hedge. > > That is actually a neat solution too. > > ___ > 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] [OSM-talk] OpenStreetMap Carto release v4.25.0
Are there many correctly tagged features with the combi barrier=hedge & area=yes where area=yes could be meant to specify something else than the hedge? Most polygon features are implicit areas, I think? Peter Elderson > Op 5 feb. 2020 om 16:22 heeft Jeroen Hoek het volgende > geschreven: > > On 05-02-2020 15:46, Christoph Hormann wrote: >> the semantic ambiguity of the > 350k cases where barrier tags are currently >> used as a secondary tag on >> landuse/leisure/etc. polygons to incidate the polygon is enclosed by a >> linear barrier. > > The PR specifically removes the filled rendering from `barrier=hedge` > mapped with `area=yes` from 36665 hedges. > > There are 36665 hedges mapped with `area=yes`. These appear to be mostly > used for hedges drawn as an area, which follows the existing documented > convention. The PR effectively deprecates the combination of > `barrier=hedge` plus `area=yes` for hedges drawn as areas, because > `area=yes` may have been intended for one of the other tags on that > entity (which breaks the 'one feature, one object' good practice), > without providing an alternative. > > No one is disputing that `barrier=hedge` on a polygon without `area=yes` > should not be considered a filled area. That part of the PR is good and > does not break the existing convention. > >> it should be noted that barrier=hedge is currently >> not the dominant method of mapping strips of trees or bushes with >> polygons > A hedge is not the same as bushes or trees. Where bushes or clumps of > trees may form some sort of barrier (although you can often barge > through them), hedges predominantly are. > > ___ > 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] Continuous Sidewalk or Cycleway
Florimond Berthoux : > No, I'm not talking about cycling on a sidewalk (I don't know why you > thought that ??), I discuss continuous sidewalk and continuous cycleway > together because it's the same layout, the same problem. > Ok, my bad. Separate tagging for continuous sidewalk and continuous cycleway. > And I'm doing that because I'm interesting in cycling infrastructure more > than others. > For instance this is a typical dutch continuous sidewalk/cycleway > https://www.mapillary.com/app/?lat=52.3608851685737=4.867902368825185=17=ru8z7_PBx5Ao2LU6TX2XfQ=photo=0.4098509000113021=0.620642840587665=0 > I know the spot, and places like it. Cycleways in Nederland can have all kinds of separation from the ways they run along, and indeed sometimes (most often not) they are elevated. If there was no continuous sidewalk at that spot, the continuity of the cycleway would not mean or implicate anything. It just telss people to expect bicycles. Cycleways along roads are often not discontinued for lower order crossing roads. There are no rules about that. Traffic from the right have priority. It is totally different from continuous foot pavement, which creates a pedestrian area where traffic is allowed if necessary, but needs to give way. In the spot shown, I would not mark the cycleway as continuous, because it does not make any difference if the red colour paving is interrupted or not, and also the kerb does not make a difference. I would mark the sidewalk as continuous because that makes a real deifferance for traffic and pedestrians. Traffic form the lesser road has to give way to all other traffic when leaving the area. So the cyclists profit from the continuous sidewalk. Again, the kerb or elevation or lining or surface of the cycleway does not matter. If there was no kerb, no elavation , and discontinued surface colour, it would be exactly the same. I don't know if that is the case only in Nederland. But I can tell you, continuous cycleway will not give any information other than that the cycleway is there. Anything you might want to deduct from that (traffic calming, access, prioryity) will need extra tagging. Assuming that certain rules are implied would be wrong in Nederland. In contrast, continous sidewalk is very common and very real here, and does imply rules. > Anyhow I updated the page > https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk > continuous_sidewalk/continuous_cycleway=yes/no are now tags, so no more > collision and can be used on the junction node or on the way. > __ > 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] Continuous Sidewalk or Cycleway
Ah, I see. You are talking about cycling on the sidewalk. Indeed, very unusual in Nederland. To me it's strange to tag continuous_sidewalk mainly for cycling. You talk of junction=continuous_sidewalk, I see no reason to even consider that. If you have a cycleway, footway or footcycleway around a roundabout, it still has crossings with the roads.which can and often will differ, so IMO the crossing nodes would carry the attributes. Well, I have given my thoughts, good luck with the proposal! Best, Peter Elderson Op za 25 jan. 2020 om 17:28 schreef Florimond Berthoux < florimond.berth...@gmail.com>: > > > Le sam. 25 janv. 2020 à 15:19, Peter Elderson a > écrit : > >> Florimond Berthoux : >> >>> With a table the pedestrians have to cross the road, it is the opposite >>> for the continuous sidewalk that's why I'm in favor to add a new value >>> >> traffic_calming=continuous_sidewalk >>> >> >> Well, any crossing involves different ways crossing each other, and >> should be considered from all angles involved. A way can't cross another >> way without being crossed itself. >> > > Crossing key is defined as such «This tag is used for more accurately > describing specific types of pedestrian crossings across roads» > Continuous sidewalk is a sidewalk, so pedestrian don't cross a road but a > sidewalk, so crossing key cannot be applied. > > >> Give ways: >>> If there is traffic sign or painting you can add a give way tag. >>> If there is none, you cannot add a give way, or you would interpret the >>> law which is not on the ground. >>> >>> Crossing: >>> I thought of using crossing key but there are issues: >>> - the tag is only for pedestrians crossing the road, where as a >>> continuous sidewalk is a sidewalk cross by cars (though we could change the >>> definition of crossing to embrace more situations) >>> >> >> I would not even consider that a change: as said above, a way can't >> cross another way without being crossed by the other way. >> >> >>> - continuous cycleways exist too (and it’s the main reason I’d like to >>> tag them) >>> >> >> In Nederland, cycleways tend to be continuous by design, but that does >> not imply anything. All the regular traffic rules apply. Only continuous >> pedestrian surface (including elevation, pavement, lining) is significant. >> It is in effect a pedestrian area or living street, where other traffic is >> tolerated but has no rights. Also, traffic coming from an area like that >> has no priority whatsoever. Movements of vehicles on the pavement are >> considered "special manoeuvres" and the driver has to give way to all >> others. >> > > Yes in Netherland you don't know what crossing a kurb every 50m on bicycle > means, but there is a difference of having the cycleway going down to join > the level of the road and crossing it than having the cycleway staying > higher than the road on a cycleway. > not continuous : > https://www.mapillary.com/app/?lat=52.10055=5.0864573=18.24231017301564=ZoLEx4v54zKtpXwEAiT_nw=photo > 5m further continuous : > https://www.mapillary.com/app/?lat=52.1002844=5.0863681=18.24231017301564=_hSpfQK3eiU4HbKEEFePIw=photo > > - it collides with continuous sidewalk, you may have continuous sidewalk >>> and a crossing, it’s not a normal case but I have at least one example in >>> Paris where zebras were added on a continuous sidewalk, hence the need for >>> another tag. >>> >> >> This would just be extra lining to emphasize priority for pedestrians. It >> looks like a zebra but It would still be a "continuous_sidewalk" crossing. >> Calling it a zebra crossing while it is continuous sidewalk would send the >> wrong message. >> > > No, I want to tag both features, I not here to interpret the world, the > law or else, I just want to say there is a continuous sidewalk with zebra > on it. > > >> For the moment my concern is about would it be possible to have tag >>> collision with junction. >>> And I just realize that a cycleway can be a junction=roundabout, and >>> being continuous at the intersection with roads in and out of the >>> roundabout. >>> >> >> That is very common around here for cycleways around a roundabout, but it >> doesn't mean anything unless traffic signs (stop signs, give_way signs or >> shark's teeth) are present. Pedestrian roundabouts, .i.e. continous sidwalk >> around a roundabout, I have never seen that, but if present, it would imply >> abso
Re: [Tagging] Continuous Sidewalk or Cycleway
Florimond Berthoux : > With a table the pedestrians have to cross the road, it is the opposite > for the continuous sidewalk that's why I'm in favor to add a new value > traffic_calming=continuous_sidewalk > Well, any crossing involves different ways crossing each other, and should be considered from all angles involved. A way can't cross another way without being crossed itself. > Give ways: > If there is traffic sign or painting you can add a give way tag. > If there is none, you cannot add a give way, or you would interpret the > law which is not on the ground. > > Crossing: > I thought of using crossing key but there are issues: > - the tag is only for pedestrians crossing the road, where as a continuous > sidewalk is a sidewalk cross by cars (though we could change the definition > of crossing to embrace more situations) > I would not even consider that a change: as said above, a way can't cross another way without being crossed by the other way. > - continuous cycleways exist too (and it’s the main reason I’d like to tag > them) > In Nederland, cycleways tend to be continuous by design, but that does not imply anything. All the regular traffic rules apply. Only continuous pedestrian surface (including elevation, pavement, lining) is significant. It is in effect a pedestrian area or living street, where other traffic is tolerated but has no rights. Also, traffic coming from an area like that has no priority whatsoever. Movements of vehicles on the pavement are considered "special manoeuvres" and the driver has to give way to all others. > - it collides with continuous sidewalk, you may have continuous sidewalk > and a crossing, it’s not a normal case but I have at least one example in > Paris where zebras were added on a continuous sidewalk, hence the need for > another tag. > This would just be extra lining to emphasize priority for pedestrians. It looks like a zebra but It would still be a "continuous_sidewalk" crossing. Calling it a zebra crossing while it is continuous sidewalk would send the wrong message. For the moment my concern is about would it be possible to have tag > collision with junction. > And I just realize that a cycleway can be a junction=roundabout, and being > continuous at the intersection with roads in and out of the roundabout. > That is very common around here for cycleways around a roundabout, but it doesn't mean anything unless traffic signs (stop signs, give_way signs or shark's teeth) are present. Pedestrian roundabouts, .i.e. continous sidwalk around a roundabout, I have never seen that, but if present, it would imply absolute priority for pedestrians and nothing for cyclists! > So I guess we have to create a key. > > I don't see how that follows from your arguments! A node on the way where it crosses the middle line of the continuous pavement (whether drawn as a way or not) tagged with either traffic_calming=continous_sidewalk or crossing=continuous_sidewalk) covers all cases mentioned, I think. Just an extra value. I think that would be enough for basic rendering, routing and traffic-oriented maps. > ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Florimond Berthoux > ___ > 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] Continuous Sidewalk or Cycleway
highway=give_way would not map the situation, just the priority. Maybe it's just me, but I think highway=give_way is an unclear tag. Who gives way to who, in what direction? I think it is better to tag it as a type of crossing. Can be rendered, can be routed. Best, Peter Elderson Op vr 24 jan. 2020 om 11:03 schreef Volker Schmidt : > > > > In Nederland, if traffic has to cross a sidewalk to get onto a road, it >> must give way to all other traffic when leaving the sidewalk. In effect, >> this cancels the priority to the right. rule.That makes it different from a >> zebra crossing, which does give priority to pedestrians, but does not >> cancel other priority rules. >> > This means in effect that here is a "give-way" situation, just no sign. > Map it as highway=give_way. > The wiki states " The highway > <https://wiki.openstreetmap.org/wiki/Key:highway>=give_way tag is used to > map points at which a traffic sign or marking instructs traffic travelling > ..." > you have some kind of marking in the form of the crossing sidewalk. > The only problem is that you may have to put a lot of these nodes on the > map. > > In that context a question (my ignorance): are there any routers that take > into account how often you have to give way (wait) when selecting the best > route? > ___ > 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] Continuous Sidewalk or Cycleway
Same thing in Nederland. Best, Peter Elderson Op vr 24 jan. 2020 om 10:55 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > In Germany, this is how the beginning / end of living streets work: > > http://www.gablenberger-klaus.de/wp-content/uploads/2014/08/K-Spielstra%C3%9Fe-1.jpg > https://upload.wikimedia.org/wikipedia/commons/1/13/Drosselweg.JPG > > 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] Continuous Sidewalk or Cycleway
So for pedestrians, you would add a node on the blue line where it crosses the centerline of the sidewalk tagged highway=crossing, crossing=? Vr gr Peter Elderson Op vr 24 jan. 2020 om 10:48 schreef Marc Gemis : > I made a quick sketch: > > https://photos.smugmug.com/OSM/Screenshots/Screenshots-1/i-w92ZnDZ/0/90e60837/X4/Bezuidenhoutseweg%20-%20Google%20Maps-X4.png > Of course, this info is then only available for the cars following the > blue road. Cycling navigation along de Bezuidenhoutseweg will not be > able to take this info into account. If you want that, you will have > to draw the cycleway as a separate OSM way. > > On Fri, Jan 24, 2020 at 10:37 AM Marc Gemis wrote: > > > > Add a node where the way, which represents the road for the cars, > > crosses the cycleway. There does not have to be a way representing the > > cycleway. We do the same for zebra crossings for pedestrians all the > > time. We add the node where the path that the pedestrians have to > > follow crosses the road for the cars. > > > > regards > > > > m. > > > > On Fri, Jan 24, 2020 at 7:49 AM Peter Elderson > wrote: > > > > > > Op vr 24 jan. 2020 om 07:38 schreef Marc Gemis : > > >> > > >> could this be solved with highway=crossing and a new, dedicated value > > >> for crossing? > > >> And you could map the kerbs before and after that crossing. > > > > > > > > > (How) would this work where sidewalks are not mapped as separate ways > but with sidewalk=yes? > > > > > > Best, Peter Elderson > > > ___ > > > 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] Continuous Sidewalk or Cycleway
"for instance in France a car driver crossing a sidewalk must give way > to others" says the wiki page. Presumably this is a different legal > case than at a crosswalk in France. > In Nederland, if traffic has to cross a sidewalk to get onto a road, it must give way to all other traffic when leaving the sidewalk. In effect, this cancels the priority to the right. rule.That makes it different from a zebra crossing, which does give priority to pedestrians, but does not cancel other priority rules. ___ > 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] Continuous Sidewalk or Cycleway
Op vr 24 jan. 2020 om 07:38 schreef Marc Gemis : > could this be solved with highway=crossing and a new, dedicated value > for crossing? > And you could map the kerbs before and after that crossing. > (How) would this work where sidewalks are not mapped as separate ways but with sidewalk=yes? Best, Peter Elderson ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Continuous Sidewalk or Cycleway
YM like here? https://www.google.nl/maps/@52.0817214,4.3213884,3a,48.3y,87.48h,90.51t/data=!3m7!1e1!3m5!1sb8Aiyn4YOsRoPIQEZWIe4w!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3Db8Aiyn4YOsRoPIQEZWIe4w%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D153.47363%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656?hl=nl=0 Traffic from the right has to cross the continuous pedestrian pavement. In Nederland, pedestrians have legal priority here, comparable to a car exit over a sidewalk. It is called "exit-construction". I pass many of these every day (the street I live in exits like that). https://www.google.nl/maps/@51.9653872,4.6089884,3a,75y,66h,76.98t/data=!3m9!1e1!3m7!1sd-J60SxVJrAWf3fp1_x-qg!2e0!7i13312!8i6656!9m2!1b1!2i47?hl=nl=0 If priority is deemed important enough for mapping, a mapping solution is needed. We had some discussion on this, but no solution was found. Best, Peter Elderson Op do 23 jan. 2020 om 21:11 schreef Florimond Berthoux < florimond.berth...@gmail.com>: > Hello, > > How to map a continuous sidewalk or cycleway ? > In order to solve this question I created a wiki page to sum up my first > try to tag this: > https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk > > The main idea is to use the tag: > junction=continuous_sidewalk|continuous_cycleway > on node or ways of a feature. > > Helpful comments are welcome. > > -- > Florimond Berthoux > ___ > 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] building=disused
TING Best, -- Peter Elderson Op wo 15 jan. 2020 om 22:54 schreef Paul Allen : > On Wed, 15 Jan 2020 at 21:17, Mateusz Konieczny > wrote: > > I would not consider disused=yes to be >> deprecated for physical objects like >> building, adits, quarries etc. >> > > The wiki for the disused prefix has been amended since the last time this > came > up, and a long way down the page, after several mentions that disused=yes > should > not be used, it concedes that disused=yes could be used on those objects. > I would > suggest that explanation should be expanded to include all physical > objects and those > exceptions given the first time disused=yes is mentioned. > > OSM Carto will handle such objects, >> without checking whatever tag disused=yes is set. >> > > English usage of modal verbs has subtle differences from other Germanic > languages, > particularly with respect to "will." OSM carto does currently ignore > disused=yes. > Are you telling me that it is guaranteed, by the core developers, that it > always > will ignore disused=yes (or, at most, render slightly differently)? If > OSM carto > core developers can give that guarantee then we can amend the wiki > accordingly, > describing when it is appropriate to use disused;key=value and when to add > disused=yes and what the effects of those two approaches will be on > standard > carto. > > If we have that guarantee, and document it, there's a chance other cartos > will > adopt the same approach. Otherwise all we can do is document that it works > that way on standard carto today, but there is no guarantee that it will > work > in the future. > > -- > 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] recreational vs functional routes
Sorry, but this is not a useful classification for bicycle routes in Nederland. Best, Peter Elderson Op zo 12 jan. 2020 om 17:34 schreef Florimond Berthoux < florimond.berth...@gmail.com>: > Le sam. 11 janv. 2020 à 22:22, Peter Elderson a > écrit : > > > > Florimond Berthoux : > >> > >> So I propose to use for bicycle route > >> bicycle:type=trekking/road_bike/commute/mtb > >> > > > > I don't think commute is a type of bicycle? Trekking maybe, but here in > Nederland they call a lot of bicycles "trekking" when they are really just > city bikes with a few extra gears and some fancy accessories. > > We also don't have a type "road bike". We do have "Omafiets" > (Grandmother's bike), mainly used by schoolgirls and young women. > Grandmothers have e-bikes, nowadays. > > bicycle:type describe the type of cycle activity of the route not > precisely the type of the bicycle. (Though commuter bike is a type of > bicycle and you have road biking in Netherland > https://en.wikipedia.org/wiki/Dutch_National_Road_Race_Championships). > So values should be (if my english is right): > bicycle:type=trekking/road_biking/commuting/mtb > > -- > Florimond Berthoux > ___ > 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] recreational vs functional routes
Peter Elderson : > Florimond Berthoux : > >> So I propose to use for bicycle route >> bicycle:type=trekking/road_bike/commute/mtb >> >> > I don't think commute is a type of bicycle? Trekking maybe, but here in > Nederland they call a lot of bicycles "trekking" when they are really just > city bikes with a few extra gears and some fancy accessories. > We also don't have a type "road bike". We do have "Omafiets" > (Grandmother's bike), mainly used by schoolgirls and young women. > Grandmothers have e-bikes, nowadays. > > There is a lot of variation in bicycle types, lots of hybrids, too, and > all have electric variants nowadays. I don't think you want them all tagged > in the routes? Just the ones having dedicated routes? > > Despite all the variations of bicycles I think very few types have > dedicated routes indicated as such on the road, in Nederland. Mtb would be > the only separately indicated type, I think, and that would include atb's. > If dedicated speed bicycle routes were signed on the roads, that would be > taggable I guess, but we don't have those. Yet? There is talk of bicycle > speedways, but so far it's just talk. > > The only other thing I see on the road is preferred routes in and around > cities. Most of the time these are not waymarked, it's just that the > signposts direct you to e.g. City Center over these routes, where shortcuts > through residential areas or parks may be available but not desirable. It's > not really a system, I think it's mainly locally decided to guide cyclists > around the block for safety. > > > ___ >> 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] recreational vs functional routes
Florimond Berthoux : > So I propose to use for bicycle route > bicycle:type=trekking/road_bike/commute/mtb > > I don't think commute is a type of bicycle? Trekking maybe, but here in Nederland they call a lot of bicycles "trekking" when they are really just city bikes with a few extra gears and some fancy accessories. We also don't have a type "road bike". We do have "Omafiets" (Grandmother's bike), mainly used by schoolgirls and young women. Grandmothers have e-bikes, nowadays. There is a lot of variation in bicycle types, lots of hybrids, too, and all have electric variants nowadays. I don't think you want them all tagged in the routes? Just the ones having dedicated routes? Despite all the variations of bicycles I think very few types have dedicated routes indicated as such on the road, in Nederland. Mtb would be the only separately indicated type, I think, and that would include atb's. If dedicated speed bicycle routes were signed on the roads, The only other thing I see on the road is preferred routes in and around cities. Most of the time these are not waymarked, it's just that the signposts direct you to e.g. City Center over these routes, where shortcuts through residential areas or parks may be available but not desirable. It's not really a system, I think it's mainly locally decided to guide cyclists around the block for safety. ___ > 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] recreational vs functional routes
Ok let's look at Berlin. I see bicycle routes in and around Berlin: https://cycling.waymarkedtrails.org/#route?id=6162=12.597273579561199!52.5315!13.4447 Are those routes touristic or commuter routes? How can you tell? I assume these have been mapped because they are waymarked/signposted. Or are you saying there is a network of commuter routes that has not been mapped yet, but deserves to be mapped? If that is the case, how do you see on the road which cycling connections are part of the commuter network? Btw, I am not against distinguishing more types of cycling routes, I am all for it, as long as it's verifyable, mappable with clear tagging, and manageable. A city commuter route network, if clearly signposted and with decent covering, certainly deserves tagging and seems very useful for rendering, planning, routing and navigating. I tend to see it as a new type of network, e.g network:type=commuter_network (tagged on the commuter routes) comparable to network:type=node_network. Best, Peter Elderson > Op 11 jan. 2020 om 19:35 heeft Volker Schmidt het > volgende geschreven: > > > I would like to return to the initial question of this thread, and looking at > it from the end users point of view. > > When in a car, I use my navigation device in real time to get as comfortably > as possible from A to B to C and so on. > I may select to avoid motorways, and may give preference to minor roads. But > if I want to go along the Route des Vins d'Alsace , my basic navigation > system will not help. In that case I have to follow the signs of the Route > des Vins d'Alsace. > > When riding my bicycle, I use a navigation web site normally off-line > beforehand, to get as comfortable as possible from A to B to Ca. Thai gives > me typically the choice t select the bicycle type: road bike, touring bike, > MTB. If I want to go along recommended tourist routes I can select a site > that gives preference to ways that follow cycle routes (i.e. a route relation > in OSM-speak with type=bicycle). The routing algorithm on that site assumes > that by selecting a bicycle route in OSM I am on a safer route (because it > makes use of bicycle infrastructure where available) but also that the route > is more interesting from the tourist perspective. > But there are - few - cycle routes in OSM that are purely indicating bicycle > commuter routes. Examples: from the routes of the small town Pesaro's > Bicipolitana (OpenCycleMap, network map) to big-city networks like Berlin, > Paris, London. > Than we have traditionally many "bicycle" routes that really are MTB routes > (because they have been created before the type=MTB had been defined). > I would assume that there are road-bike bicycle relations in OSM, but don't > know any example. > So yes, it makes perfect sense to distinguish different bicycle route types. > > >> On Fri, 10 Jan 2020 at 09:29, Peter Elderson wrote: >> >> Andy Townsend : >>> Peter Elderson wrote: >>> > Warin <61sundow...@gmail.com> het volgende geschreven >>> > >>> >> I think; >>> >> Those who bicycle know why there needs to be these classes. >>> >> Those who don't ride a bicycle regularly see no need for these classes. >>> > I wonder which of these groups you think I am in... >>> > >>> > Hint: Nederland. >>> >>> Ahem. How can I put this tactfully - the Netherlands doesn't exactly >>> have the widest variety of cycling terrain in the world, and has a >>> generally good network of separated cycleways. >> >> You would be surprised... but that wasn't the issue. THe examples show no >> extrapordinary ways or routes. Characteristics of ways in a route are >> tagged on the way, such as surface, elevation, speed, access, oneway. >> Characteristics of the whole route are tagged on the relation. I would only >> create a route relation for a route that's actually visible, i.e. waymarked. >> For bicycles we have route=bicycle, for mtb we have route=mtb. Chracterizing >> routes as especially suited for or designated as touristic or speed cycling, >> if that was a common thing visible on the ground, no problem. I am sure >> examples can be found. I am not sure it is enough to warrant tagging. >> On the other hand, if someone or a group of cyclists intend to tag the >> visible or obvious (?) purpose(s) of routes in a particular country in more >> detail, and makes a nice special interest map of it, fine! I would not >> expect random mappers around the globe to map it, though. >> ___ >> 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] hiking and foot route relations - is there any consistent difference?
+1 If don't see this as a problem. If more clarity is needed, add tags for specific aspects. E.g "vigour" scale if one exists. Boot type recommendation scale, where 1=flipflop and 10=hoverboots. Mvg Peter Elderson > Op 11 jan. 2020 om 14:59 heeft Joseph Eisenberg > het volgende geschreven: > > Back in August there was a thread titled "Merging tagging scheme on > wiki pages of Hiking, route=hiking, route=foot and Walking routes" > which led to a new template > https://wiki.openstreetmap.org/wiki/Template:Tagging_scheme_for_hiking_and_foot_route_relations > - used on route=hiking and route=foot pages. > > However, I'm disappointed that the text ended up claiming this: > > "route=foot is used for routes which are walkable without any > limitations regarding fitness, equipment or weather conditions. As a > guideline, you could say that walking shoes (at a pinch, even > flip-flops) are adequate for this type of walking trail." > > This is all quite subjective. Folks here in Indonesia climb 3500 meter > mountain passes in flip-flops. > > "route=hiking is used for routes that rather match Wikipedia's > definition: "A long, vigorous walk, usually on trails, in the > countryside"). As a guideline, you could say that a hiking trail needs > hiking boots because you will encounter sharp rocks and/or heavy > undergrowth and/or muddy terrain and/or have to wade through shallow > streams." > > Again, very Western / European perspective to mention "needs hiking boots". > > I asked about this on the wiki talk page, and Brian de Ford said: > > "Google walking versus hiking and you will get many results agreeing > that there is a distinction. No two of them entirely agree on what the > differences are, but there is core agreement that hiking is more > vigorous than walking. One insists that there must be a change in > elevation (just about every road and sidewalk around here involves > changes in elevation, so by that definition I hike to the shops). > Several agree that equipment required makes a difference (style of > footwear and need for a cane/stick). Many say that the nature of the > surface makes the difference. Others say it's the terrain. There's a > difference, but it may be hard to agree on definitions for OSM. BTW, > parts of the UK also have "hillwalking" (which appears to be hiking > where hills are involved) and rambling (essentially unmappable because > there is no route)." > > It sounds like there is no verifiable difference between route=foot > and route=hiking, so database users should not expect these tags to be > used in a consistent way. Each mapper has there own idea of what they > mean. > > - Joseph Eisenberg > > ___ > 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] Rare route values route=inline_skates and route=running
For Nederland: yes and yes. Vr gr Peter Elderson Op za 11 jan. 2020 om 06:23 schreef Joseph Eisenberg < joseph.eisenb...@gmail.com>: > The tag route=inline_skates was added to Map features, but it has > only been added a few times in the past 4 years. > > Are there actually signed, verifiable inline skate routes? > > Should a rare tag like this be in Map Features? > > Similar questions about route=running - are there real, signed running > routes which are separate from walking or hiking routes? > > - Joseph Eisenberg > > ___ > 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] recreational vs functional routes
Andy Townsend : > Peter Elderson wrote: > > Warin <61sundow...@gmail.com> het volgende geschreven > > > >> I think; > >> Those who bicycle know why there needs to be these classes. > >> Those who don't ride a bicycle regularly see no need for these classes. > > I wonder which of these groups you think I am in... > > > > Hint: Nederland. > > Ahem. How can I put this tactfully - the Netherlands doesn't exactly > have the widest variety of cycling terrain in the world, and has a > generally good network of separated cycleways. > You would be surprised... but that wasn't the issue. THe examples show no extrapordinary ways or routes. Characteristics of ways in a route are tagged on the way, such as surface, elevation, speed, access, oneway. Characteristics of the whole route are tagged on the relation. I would only create a route relation for a route that's actually visible, i.e. waymarked. For bicycles we have route=bicycle, for mtb we have route=mtb. Chracterizing routes as especially suited for or designated as touristic or speed cycling, if that was a common thing visible on the ground, no problem. I am sure examples can be found. I am not sure it is enough to warrant tagging. On the other hand, if someone or a group of cyclists intend to tag the visible or obvious (?) purpose(s) of routes in a particular country in more detail, and makes a nice special interest map of it, fine! I would not expect random mappers around the globe to map it, though. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Warin <61sundow...@gmail.com> het volgende geschreven > I think; > Those who bicycle know why there needs to be these classes. > Those who don't ride a bicycle regularly see no need for these classes. I wonder which of these groups you think I am in... Hint: Nederland. > For those that see no need for these classes .. what harm will they do to the > data base? > > I am ignoring the 'verification' argument for the time being. > > P.S. I personally see no need to specify how a power line is attached to a > pole .. others are quite happy to map such detail. So I have no objection to > there mapping, I will never use it nor map it. > > > On 10/1/20 7:36 am, Peter Elderson wrote: >> I don't see why it's not a type=route route=bicycle. Bicycle routes do not >> have to be exclusive or any particular type of road, just signposted as a >> bicycle route. You can tag extra attributes of course. >> >> Best, Peter Elderson ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
> You don't need signpost to have a route. I disagree. If there is nothing on the ground, there is no mappable route. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
Florimond Berthoux het volgende geschreven: > > > Ok, you need examples : > this Eurovelo 3 is for tourism > https://www.openstreetmap.org/relation/9351172#map=12/48.8454/2.4130=C > this REVe Nord-Sud is for commute/every day cycling > https://www.openstreetmap.org/relation/8664006#map=14/48.8784/2.3599=C > as you can see in this video https://youtu.be/1dGtSZbUKew > and this is for road cycling > https://www.openstreetmap.org/relation/163270#map=15/48.8577/2.2333=C > as you can see in this video https://www.youtube.com/watch?v=VLwNlVjTOKU > I can't see the signposting of the routes in the videos, I assume because I don't know where to look? > Of course nobody will blame you if you use a touristic route for commuting, > and adding a tag tourism=yes doesn’t imply it can’t be used by every day > cyclists. > > What the point? If you are a commuter you’ll focus on fast and safe route, so > you’ll prefer REVe Nord-Sud than Eurovelo 3 at this place > https://www.cyclosm.org/#map=18/48.86796/2.35391/cyclosm > For instance, this information can be used for rendering map (like CyclOSM on > which I work) or routers (a tourist profile routing will prefer tourism > route). (just playing devil's advocate) Wouldn't renderers and routers prefer road attributes? >> ___ > 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] recreational vs functional routes
I don't see why it's not a type=route route=bicycle. Bicycle routes do not have to be exclusive or any particular type of road, just signposted as a bicycle route. You can tag extra attributes of course. Best, Peter Elderson Op do 9 jan. 2020 om 21:15 schreef Richard Fairhurst : > Joost Schouppe wrote: > > In the case of cycling, it would be really useful > > for routers to be able to differentiate. > > Yes - with my cycle.travel hat on, I'd find this very useful. Just an > optional route_type= tag on the relation would help. > > I've mentioned on here a couple of times before [1] that there's a road > bike > route in North Wales that is particularly problematic: it's signposted as a > bike route, but whereas other routes in the UK are for utility or touring > purposes, this one is specifically for road bike training and is wholly > unsuitable for all other purposes. (Almost all of its route is > highway=trunk > or highway=primary with no cycling provision whatsoever.) Although it's a > signposted bike route and as such merits mapping, it is no more akin to a > standard route=bicycle than a stretch of mountain bike singletrack is. > > cheers > Richard > > [1] > https://lists.openstreetmap.org/pipermail/tagging/2019-October/048713.html > , > > https://lists.openstreetmap.org/pipermail/tagging/2019-September/047873.html > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html > > ___ > 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] recreational vs functional routes
waymarked mtb routes are tagged route=mtb on the relation waymarked cycling routes are tagged route=bicycle on the relation. I don't know how I could verify that a cycling route is either touristic or for commute/everyday cycling or both. Even if advertised as touristic it can be used for commute/everyday cycling, ande the other way around. I do not foresee significant mapping of these purposes. Best, Peter Elderson Op do 9 jan. 2020 om 15:08 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > Am Do., 9. Jan. 2020 um 10:41 Uhr schrieb Florimond Berthoux < > florimond.berth...@gmail.com>: > >> tourism=yes : if the cycle route is a touristic purpose route >> commute=yes : if it's a route for commute and every day cycling >> > > > where do you get this information from? Is it verifiable? > > > >> road_bike=yes : if it's a route to do road biking sport >> mtb=yes : if it's a cycle route mtb oriented >> > > > to some extent the mtb=yes tag this is already covered (in greater detail) > by presence of mtb:scale tags > maybe it could be extended for road_bike as well (e.g. mtb:scale=-1). Also > smoothness could help. > > https://wiki.openstreetmap.org/wiki/Key:mtb:scale > https://wiki.openstreetmap.org/wiki/Mountain_biking > https://wiki.openstreetmap.org/wiki/Key:smoothness > > 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] recreational vs functional routes
If a route meant for motor vehicles is waymarked as a recreational route, why not use the same tagging system as for other recreational routes? [relation] type=route route=Xmn where X=l (local), r (regional), n (national) or i (international) an mn is motor network (name=...) (operator=...) (symbol=...) (osmc:symbol=...) and other relevant tags If the route is waymarked in both directions, chances are there will be a lot of differences. You could use the role-based backward/forward ways system as is usual in cycling routes or use separate relations for the directions, then put them together in a parent relation. The roles in routes discussion would then apply, too. Fr gr Peter Elderson Op di 7 jan. 2020 om 20:52 schreef Marc Gemis : > AFAIK, routes such as the Krekenroute in Belgium as signposted with > https://images.app.goo.gl/bFnEWw7FVoyfq83x8 (although I thought at on > some signs there is also the silhouette of a car) > > On Tue, Jan 7, 2020 at 8:39 PM Peter Elderson wrote: > > > > joost schouppe : > > > > > Especially for car routes, I haven't seen any way to tag touristic > routes for driving cars, like the Turist Veger in Norway or the Route des > Cols in France > > > > Are these routes waymarked as special routes? > > > > > ___ > > > 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 > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] recreational vs functional routes
joost schouppe : > Especially for car routes, I haven't seen any way to tag touristic routes for > driving cars, like the Turist Veger in Norway or the Route des Cols in France Are these routes waymarked as special routes? > ___ > 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] Roundtrip and closed loop in relations
True! I have seen a few educational or theme routes that way. In that case it's meant to be a roundtrip, or you make a roundtrip using the same way back by necessity. Regular linear hikes are not meant to be used as roundtrips, though you could go back the same way of course. I would use roundtrip=yes only for routes designed for roundtrips. Which can encompass a lot of geographical layouts, even single chain linear routes as illustrated by your example. A closed_loop would automatically qualify as a roundtrip, I think, but I trust someone will come up with an exception! Fr gr Peter Elderson Op ma 23 dec. 2019 om 08:52 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > > > sent from a phone > > > On 22. Dec 2019, at 16:43, Peter Elderson wrote: > > > > A linear walking route marked in both directions is not a roundtrip. > You're not guided to turn around at the end and return to the start. > > > there are cases where it’s unavoidable, because there is only one way. > > 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] Roundtrip and closed loop in relations
Good point. I would say roundtrip is the service provided. But if a route
is designed for roundtrip service i.e. if you remain seated you end up at
the starting point, roundtrip becomes an attribute of the route. However,
most PT allows you to book or perform a roundtrip. Because even if you get
off and later back on, even on a different vehicle and/or by a different
route, it's still a roundtrip, no matter the layout of the routes.
(Nederand used to have roundtrip tickets, priced at 1 1/2 the cost of two
separate single way tickets. You could get roundtrip tickets ("retours")
valid on one day, or roundtrips with open return day. Now, we pay per
kilometer, so that's history. For now!).
In short, I think circular would be the better term if the route is
"circular". I would not retag, though. I am not a PT-mapper or PT datauser.
But I have to ask: is it absolutely clear what it means if a PT-route is
mapped as a roundtrip? Is this information really used?
Fr gr Peter Elderson
Op zo 22 dec. 2019 om 15:34 schreef marc marc :
> 3 240 (10%) objects with rountrip=3 also have public_transport:version=*
> ex https://www.ratp.fr/plans-lignes/noctilien/n01
> https://www.openstreetmap.org/relation/1083331
>
> Le 22.12.19 à 11:57, Peter Elderson a écrit :
> > For PT, roundtrip is not an attribute of the route
> >
> >> Op 21 dec. 2019 om 15:31 heeft marc marc het volgende geschreven:
> >>
> >> I always thought that routrip=yes was an alternative when there is no
> >> start and end point to enter in from=* to=* key.
> >> Otherwise circular routes with a known start/end point can enter
> >> as from=A via=B to=A.
> ___
> 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] Roundtrip and closed loop in relations
> > If following the route marking you will get back to start... It's a circular > route. > As previously stated you could find marking on both directions and be a > single line straight and then reverse. > With old wiki definition this is Roundtrip=no... Now it is Roundtrip=yes > Seems sane to me. A linear walking route marked in both directions is not a roundtrip. You're not guided to turn around at the end and return to the start. You are free to do that and make your cross-the-alps trail a roundtrip, of course, but I have yet to encounter anyone who does that. Could become an Australian hype maybe? :) So no, I wouldn't expect linear walking routes to get tagged as roundtrip=yes. circular is fine too, as long as it can be applied to routes that are not strictly circular (closed_loop). Such as having a common approach/exit section, crossing itself one or more times, or having a common middle section between two loops. This would still qualify as roundtrip to me, because the 'service' i.e. the waymarking, brings you back to the start. bidirectional waymarking does not a roundtrip make, it just says you can choose to do the hike in both directions. At the same time, if circular just means the same as roundtrip (for walking routes), I would not change current tagging. Lots of work to achieve nothing, not my favorite. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Roundtrip and closed loop in relations
For PT, roundtrip is not an attribute of the route, it's a type of ticket or it's what you use the transport for. You can do a roundtrip on a circular line, but also on non-circular lines or mostly non-circular with a loop at the end, whatever. To express that a PT route is circular, I think the term circular would be better than roundtrip. For hiking|foot routes, exception is the rule when it comes to branches, alternatives, excursions, approaches and shortcuts. For me roundtrip on a walking route relation means: when you keep following the main route markings, it takes you back to where you begun. This does not exclude any alternatives, such as optional extra loops or a common approach/exit route at a starting point. Only roundtrip=yes is needed here, if not present assume it's not a roundtrip. Note that many trails consist of a number of linear routes, together making for a roundtrip. I tag roundtrip=yes only on the parent route relation. Loop or circular would also be just fine, but I see no reason to change existing tagging here. Question: who wants to know if a route is a circular route/loop/roundtrip? Is it the map user? No, (s)he can see it on the map. Is it important for routing and navigation? I can't see how, but there are experts on this list who know more about this. So far I know of only one application: categorisation/filtering of trips in order to present the user a choice between roundtrip walks or linear walks. The roundtrips were actually meant to be daytrips, and linear walks were to be presented as " long distance walks", but a separate category long distance roundtrips could be deducted from the data, I guess. Question: who wants to know if a route is actually a closed loop without any branches? What do you need this information for? So far, I know one application: if a route is tagged as a closed loop, e.g. with closed_loop=yes, and it's not complete or interrupted somewhere, you can detect that with a checking tool. It would be a sort of fixme, then. Most routes I maintain would not profit from that. FrGr Peter Elderson > Op 21 dec. 2019 om 15:31 heeft marc marc het > volgende geschreven: > > I always thought that routrip=yes was an alternative when there is no > start and end point to enter in from=* to=* key. > Otherwise circular routes with a known start/end point can enter > as from=A via=B to=A. > ___ > 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] Roundtrip and closed loop in relations
I think roundtrip is not about the route taken, but about the transport taking you somewhere, you do your thing there, then transport back to where you started. It's more like a service kind of thing. I don't use it when the relation shows exactly what the route is. I only find it useful to indicate that a route should be regarded as a roundtrip, even though the relation contains branches, excursions or shortcuts. For hiking, a hiking route A to B waymarked in two directions is not a roundtrip. A hiking route ending where you started when you follow one direction all the time, may be seen as a roundtrip, because the 'transport' takes you back to back to to starting point. Mvg Peter Elderson > Op 20 dec. 2019 om 04:21 heeft Graeme Fitzpatrick het > volgende geschreven: > > > > > >> On Fri, 20 Dec 2019 at 10:37, Martin Koppenhoefer >> wrote: >> >> it’s in the “back again”, makes it likely you take the same way. > > Sorry, Martin, not at all. I do a weekly round trip of ~38 klm - roughly 13 k > down & 15 k back, mainly because I leave the Motorway at exit 92 but have to > come back on at exit 95. & if the Motorway is too busy that day, I may well > come home up the Highway, which will be 12 k home (but 15 minutes longer > time), but it's still a "round trip" > > Also, what is the definition of "same way"? > > I travel down the southbound lanes of the Motorway & come back up the > northern lanes, about 100 m's away from where I travelled down - is that the > "same"? > > 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] Roundtrip and closed loop in relations
If a route ends where it begins, it's a roundtrip, but you don't need to tag that because it's in the relation. The only thing I find useful is tagging roundtrip=yes when the route is not a true closed loop, but still catalogues for hikers as a roundtrip, even though it may have branches and shortcuts. For automated checks closed_loop=yes might come in handy. If the tag is there but the route is not a true closed loop, it needs maintenance in OSM. Mvg Peter Elderson > Op 19 dec. 2019 om 22:40 heeft Martin Koppenhoefer > het volgende geschreven: > > > > sent from a phone > >> On 19. Dec 2019, at 22:16, Volker Schmidt wrote: >> >> you have changed the meaning of the tag from inluding the possibility of a >> loop to exluding it. > > it may be too early to change definitions, but previous discussions have > shown that there was confusion about the roundtrip tag also before, and the > definition that start and end of the route have to be the same is also > satisfied with actual roundtrips (A-B and back). > IMHO we should discourage the roundtrip tag altogether and establish > alternative tags for the cases that should be covered (loops and back and > forth or oneway) if they are required. > > 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] Rail segment in a bike route
A router should never assume that a route tag overrules a way or node tag, for access. Vr gr Peter Elderson Op za 14 dec. 2019 om 15:43 schreef Volker Schmidt : > > > > Adding a bicycle=dismount is OK I suppose, but I'm unsure there's really >> a problem. > > This street in Padova <https://www.openstreetmap.org/way/27212508> > carries a (mono-rail) tram (railway=tram) and is closed to bicycles, tagged > with bicycle=no. > I intended to re-tag this with bicycle=dismount in line with the notion > that you are allowed to push your bike along, like you are allowed to push > your bike across the pedestrian area in the city center. > I would not have dreamed that this would mean that I would have to take my > bicycle on the tram (which I am not allowed to do anyway). > > >> Routing software creators will always refer to tags on the ways. Common >> sense needs to be exercised - If a router comes across 'railway' >> 'dismount' should be a assumed. >> > Some bicycle routers take into account the fact that a way is part of a > bicycle route. > ___ > 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 - hiking_trail_relation_roles - transport
if all the ideas for roles in routes are combined, you will need multiple roles for the relation members. When a member of a cycling route relation is tagged as a waterway or a railway, isn't that all the information you need to know it's a transfer? If the member is a relation, you could tag it with the transport mode. So the network tag for the section would remain for example ncn, and add a tag to indicate it's e.g. a train transfer. Fr Gr Peter Elderson > Op 14 dec. 2019 om 09:17 heeft Warin <61sundow...@gmail.com> het volgende > geschreven: > > Where a hiking route uses some transport to get from one walking section to > another should there be a roll 'transport'??? > > I know one of the American routes uses a canoe to cross a river, and at least > one of the Australian routes uses row boats to cross a river. > > And, yes, this flows on from the bicycle route that uses a train for some > length. > > > ___ > 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] Rail segment in a bike route
We happily add ferry transfers to hiking routes. Nobody has been found trying to walk on the water. Nobody that we know of... Fr gr Peter Elderson Op vr 13 dec. 2019 om 20:39 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > > > sent from a phone > > On 13. Dec 2019, at 18:37, Francesco Ansanelli > wrote: > > I added a bicycle route that implies the use of a funicular (railway). > I'm not sure how to "tell" in the relation that you have to take the train > and not ride the railway. > Can you give me some hint? > > > > I am not sure there is an agreed way to express this. From a cycling point > of view the route is interrupted at this point > We would have to introduce multimodal relations to cater for situations > like this > > 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 - hiking_trail_relation_roles
An approach always links something to the route so yeah, fine with me. Fr gr Peter Elderson Op vr 13 dec. 2019 om 14:29 schreef John Willis via Tagging < tagging@openstreetmap.org>: > > > On Dec 13, 2019, at 2:20 AM, Michael Behrens > wrote: > > > > I would agree that a 'link' should be tagged as a approach > > > > Then the word "approach" shouldn’t be used - use “link”. Use the same > vocabulary as other route relations. > > We shouldn't use bespoke words when the standardized synonym word is > already used in tagging other route relations. > > if there is some major difference between an approach and a link, then > sure, but it really sounds like a link. > > > ___ > 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 - hiking_trail_relation_roles
I think in terms of this proposal, a waymarked link is an approach? Vr gr Peter Elderson Op do 12 dec. 2019 om 11:21 schreef John Willis via Tagging < tagging@openstreetmap.org>: > Links - as in a relation role value “link” - as in small pieces of trail > that link some other trail or way to the main route. > > Just thinking of routing Terms we use for other types of routes. > > Javbw > > > On Dec 12, 2019, at 2:22 PM, Warin <61sundow...@gmail.com> wrote: > > > > What links? urls? or do you mean ways that connect the route to > bus/train/etc? In which case I think those can be role approach ? > > > ___ > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
To sum up, checkpoints and trailheads deserve to be mapped. Once they are features mapped and tagged as nodes, they can be rendered, searched and used as POIs. Questions: Is it useful to include them as node members in the hiking route relation(s) or is the spatial relationship enough? If included, do they need a member role? If so, would "checkpoint" and "trailhead" be acceptable and useful role values? Would it be acceptable/useful for mappers to include a node in a route relation with a "checkpoint" role without any tagging? Fr gr Peter Elderson > __ > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
Yes I know... I trust nobody will rely on OSM for their life, unless the rescue service itself checks and guarantees that the data is 100% correct and complete. But it's nice if they are mapped. Fr gr Peter Elderson Op ma 9 dec. 2019 om 23:25 schreef Warin <61sundow...@gmail.com>: > On 09/12/19 19:43, Peter Elderson wrote: > > > Jmapb : > >> On 12/8/2019 6:44 PM, Peter Elderson wrote: >> >> > >> > Could you envision a node passed by two hikes, and being a checkpoint >> > for the one and nothing special for the other? >> >> Camino de Santiago ( https://www.openstreetmap.org/relation/153968 ) >> comes to mind. Hikers doing the whole route carry passports that are >> stamped at checkpoints along the way, to document completion of the >> route. Hikers not attempting to complete the whole route probably >> wouldn't have the passport and wouldn't bother with the checkpoints. >> > > I have walked many "Camino" sections in Italy. The "checkpoints" are just > stamps, you can get them at many shops, hotels, restaurants, tourist info > points and the like on the way. They will stamp anything for anyone who > asks. There is no register, nothing is checked. I would not call them > checkpoints and I would certainly not attempt to map them. In Nederland, I > don't know about shops, hotels and restaurants. > On the other hand, there are special places like convents and some > churches where pilgrims can stay the night and eat very cheap or free. They > would check and maybe register the pilgrim's passport, I guess. These > points would merit rendering and routing, I think. I don't know if it helps > to tie it to a particular route though. It's a POI passed by one or more > routes. The map can show it, routers can use it and it can be exported in a > gpx or kml. > > It's one of those things I would not map unless I can be reasonably sure > it will be maintained and used for actual rendering, routing and/or export. > > > There are checkpoints that are used for safety. These are checked by > search and rescue services when people are overdue, or tracks get closed by > fires or very bad weather. They are not tourist 'look at me, this what I > have done' type things... but thing to prevent death. > > > ___ > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
Yes. I have no principle problem with checkpoint members or other useful node members, if the membership of the relation provides useful information that cannot be easily extracted otherwise, by tagging a feature or simple node as a checkpoint. Same goes for trailheads. Start/endpoints are another issue. Hikes in Nederland tend to have a lot of intermediate hopon hopoff points, in fact every junction is a start/endpoint! The only real starting point is the first node of the first way, which is already in the relation. Likewise, end point is the last node of the last way. Why enter these nodes again? True roundtrips (roundtrip=yes, closed_loop=yes) also have a starting point in the relation, which happes to be the same as the ending point. Note that this holds true for sequentially ordered relations. This gives you start, end, main direction. If the relation also has members with roles (other than the forward/backward roles used for ways mainly in cycling relations) separate start-endpoints and main directions could be determined per role. Of course, you could, no will have multiple variants with the same role in almost all long hikes... Well, data consumers will probably tell me not to worry! I also know a trail along a national border which features hundreds of numbered border stones. Maybe add a milestone role? Fr gr Peter Elderson Op ma 9 dec. 2019 om 22:40 schreef Jmapb : > On 12/9/2019 3:43 AM, Peter Elderson wrote: > > > I have walked many "Camino" sections in Italy. The "checkpoints" are just > stamps, you can get them at many shops, hotels, restaurants, tourist info > points and the like on the way. They will stamp anything for anyone who > asks. There is no register, nothing is checked. I would not call them > checkpoints and I would certainly not attempt to map them. In Nederland, I > don't know about shops, hotels and restaurants. > On the other hand, there are special places like convents and some > churches where pilgrims can stay the night and eat very cheap or free. They > would check and maybe register the pilgrim's passport, I guess. These > points would merit rendering and routing, I think. I don't know if it helps > to tie it to a particular route though. It's a POI passed by one or more > routes. The map can show it, routers can use it and it can be exported in a > gpx or kml. > > It's one of those things I would not map unless I can be reasonably sure > it will be maintained and used for actual rendering, routing and/or export. > > Haven't hiked any bits of the Camino myself, so my impressions are > secondhand, but I was told some places -- I think the second type you > mention, the convents etc -- are required checkpoints for official > completion of the route. And to any other passers-by, they're simply a > convent, an inn, whatever amenity they actually are (and of course should > be mapped as such.) > > Regardless of whether this is a correct description of the way checkpoints > function on the Camino de Santiago, it's an illustration of how a > checkpoint COULD relate to a particular route but not to another that > shares the same way. So if (big if) we want hiking route relations to > support non-highway members, this is something to consider. > > J > ___ > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
Jmapb : > On 12/8/2019 6:44 PM, Peter Elderson wrote: > > > > > Could you envision a node passed by two hikes, and being a checkpoint > > for the one and nothing special for the other? > > Camino de Santiago ( https://www.openstreetmap.org/relation/153968 ) > comes to mind. Hikers doing the whole route carry passports that are > stamped at checkpoints along the way, to document completion of the > route. Hikers not attempting to complete the whole route probably > wouldn't have the passport and wouldn't bother with the checkpoints. > I have walked many "Camino" sections in Italy. The "checkpoints" are just stamps, you can get them at many shops, hotels, restaurants, tourist info points and the like on the way. They will stamp anything for anyone who asks. There is no register, nothing is checked. I would not call them checkpoints and I would certainly not attempt to map them. In Nederland, I don't know about shops, hotels and restaurants. On the other hand, there are special places like convents and some churches where pilgrims can stay the night and eat very cheap or free. They would check and maybe register the pilgrim's passport, I guess. These points would merit rendering and routing, I think. I don't know if it helps to tie it to a particular route though. It's a POI passed by one or more routes. The map can show it, routers can use it and it can be exported in a gpx or kml. It's one of those things I would not map unless I can be reasonably sure it will be maintained and used for actual rendering, routing and/or export. ___ > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
I have some doubts about the need to link the feature to the relation. The node is already in or possibly very near the route, and the feature could be tagged, displayed and routed as a type of POI. But, if entered into a route relation, role checkpoint sounds ok to me. Then it could be displayed with an icon even if not tagged. Fr gr Peter Elderson Op ma 9 dec. 2019 om 01:11 schreef Warin <61sundow...@gmail.com>: > On 09/12/19 10:44, Peter Elderson wrote: > > Ok, just asking to make sure. > > > As an overview most hiking things are on > https://wiki.openstreetmap.org/wiki/Hiking > > > Could you envision a node passed by two hikes, and being a checkpoint for > the one and nothing special for the other? > > > Yes. > > > Would a checkpoint need to be a node of a way in the relation? > > > If it only relates only to that relation then quite possibly. > > If it is a required activity for that route then I would think so. This > would link it to the operator, route name etc, possibly minimising the work > of mappers and reducing errors? > > > Vr gr Peter Elderson > > > Op ma 9 dec. 2019 om 00:16 schreef Kevin Kenny : > >> On Sun, Dec 8, 2019 at 6:10 PM Peter Elderson >> wrote: >> > Is a checkpoint a feature in itself? >> >> Of course it is. A way segment is also a feature in itself, which >> doesn't mean that it can't or shouldn't be part of a route relation: >> "When you're hiking this route, you'll need to sign in at these >> points." > > > https://wiki.openstreetmap.org/wiki/Key:checkpoint > ___ > 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 - hiking_trail_relation_roles
I am now convinced it is useful to have a oneway=yes tag for a route indicating it's not allowed or possible to go the other way. As for routers, I would still expect a router to check all the ways and nodes for access. Fr gr Peter Elderson Op ma 9 dec. 2019 om 00:36 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > > > sent from a phone > > > On 7. Dec 2019, at 16:49, Mateusz Konieczny > wrote: > > > > Only-exit ways in zoos, Orla Perć hiking trail, > > some tourism routes in castles, mines etc > > > don’t know for the hiking trail, but the other cases are not what I would > see as “legal prescriptions”, it’s what the operator has decided. > > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
Ok, just asking to make sure. Could you envision a node passed by two hikes, and being a checkpoint for the one and nothing special for the other? Would a checkpoint need to be a node of a way in the relation? Vr gr Peter Elderson Op ma 9 dec. 2019 om 00:16 schreef Kevin Kenny : > On Sun, Dec 8, 2019 at 6:10 PM Peter Elderson wrote: > > Is a checkpoint a feature in itself? > > Of course it is. A way segment is also a feature in itself, which > doesn't mean that it can't or shouldn't be part of a route relation: > "When you're hiking this route, you'll need to sign in at these > points." > > ___ > 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles
Is a checkpoint a feature in itself? Fr gr Peter Elderson Op zo 8 dec. 2019 om 23:48 schreef Kevin Kenny : > On Sat, Dec 7, 2019 at 12:29 PM Jmapb wrote: > > On 12/7/2019 11:52 AM, s8evq wrote: > > > In my limited experience mapping hiking routes, I have not yet come > across any real use for nodes in hiking relations, but I'm curious if other > people have good uses. > > > As far as I know, there is also not much documented in the wiki on the > topic of nodes in hiking/cycling relations. > > Possibly for checkpoints? > > Good idea. In at least some places where I travel, there are > _mandatory_ checkpoints: “No person shall fail to register whenever > passing a trail register established by the department in the Eastern > High Peaks Zone.” (N.Y. Comp. Codes R. & Regs. tit. 6 § 190.13(f)(1) > https://tinyurl.com/sdqfl2d) > -- > 73 de ke9tv/2, Kevin > > ___ > 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 - hiking_trail_relation_roles
Sarah Hoffmann : > On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote: > > Also, i guess backward and forward roles are for ways only, the other > > roles are more suited for relation members. Or not? Could I enter all the > > ways of a 3 Km medieval castle excursion to a viewpoint into the hiking > > relation holding the ways of the main route, each with the 'excursion' > > role? I think this should be explicit. > > > > It seems to me that use of these roles leads to relations containing > > non-contiguous trails. I would call those relations collections rather > than > > routes. Processing non-contiguous routes presents extra challenges for > > processing such as exporting routes and making elevation profiles. > > I have to strongly disagree with all of that. > > 1. Having alternatives and excursions does not make a route non-contiguous. >It just makes it non-linear. > You are right, I used the wrong word. Non-linear. In practice most long routes I work with also have gaps, in addition to branches, shortcuts, extra loops, alternatives, full length variants, variants of variants and completely separated variants e.g. island loops which are seen as part of a longer route or collection. In addition, local routes are often part of regional routes, (parts of) regional routes are sections of national routes, and (part of) the main route of a national route is the national section of an international route which can have completely separated alternatives. > 2. It is perfectly normal for a route to be non-linear. If the alternative >route is marked, it's part of the route and should be mapped > accordingly. > Of course. But it's not always clear what "the route" is! We (Nederland) have routes consisting of several sections carrying their own trail names. Sometimes people know them by their collective name, sometimes only the separate names of the section paths. Many separate routes have identical waymarking, and most of the waymarks carry no path name, so that does not help. > 3. Non-linear routes are not a problem for processing per-se. > > The point about the processing you have now made repeatedly in different > contexts. You seem to have come to this conclusion because waymarkedtrails > does not implement non-linear routes. As much as it honors me that you > consider waymarkedtrails the gold standard for what is doable with route > relations, I have to disappoint you here. Non-linear routes are simply not > implemented because of lack of time. > I'll take your word for that, but I do not see it yet! The proposal says it's on your request, so considering the processing by waymarkedtrails seems appropriate. Is that what the requested roles are intended for, if you can find the time? Or do you mean processing of non-linear routes without special roles? Can this result in exports usable for navigating by OsmAnd, Garmin and the like? Will it solve your discontinuous profile issue for non-linear routes? > If I'd have to state a rule what makes processing easier then it would be: > avoid subrelations unless the relation is so large that it is a pain to > handle in the editor. > The wiki about that says over 300 ways. I agree. More is not immediately fatal, but from 300 on maintenance effort increases significantly because errors (chain breaks and sorting errors) by other editors will happen more often, are more difficult to track, and sorting functions do not handle these errors well. Non-linearity also frustrates sorting and maintenance. The main route of nearly all route relations I regularly maintain are far more than 300 members in total. So they will be split into parts conform the wiki. Of course there is no special relation type "sub-relation", that just means it's a route-in-a-route. Variants can be short or long, the longer ones can e.g. consist of 3 day's walking, which merits one ore more separate route relations for the variant. Variants and main route are then assembled in a route relation of type route or sometimes superroute. I assumed handling this is accepted practice and will continue to happen. The question at hand is, should the proposed roles be applicable only to ways, or also to other elements in the route relations? If so, the proposal should state that, I think, and also what exactly it means, e.g. what exactly does forward mean for a (sub)relation element, and whether a particular sorting order is required. ___ > 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 - hiking_trail_relation_roles
Ok I forgot. So signed_direction=yes means signed in the direction of the sequence of ways in the relation. signed_direction=no would be the default for hikes, then? And oneway=yes on a hiking route means it's really one way (direction is given by the order way sequence) and you are not allowed to use it in the other direction. Again, oneway=no would be the default for pedestran routes. I would like to add thee values and defaults to the wiki, because now it only states the key. Does it hold true for other recreational routes, such as cycling, horse routes, skiing, paddling, mtb? Can these be assumes to be accessible and signed in both directions if no oneway tag and no signed_direction tag are present? Fr gr Peter Elderson Op za 7 dec. 2019 om 17:38 schreef s8evq : > > On Sat, 7 Dec 2019 01:09:37 +0100, Martin Koppenhoefer < > dieterdre...@gmail.com> wrote: > > oneway is generally not considered to apply to pedestrians. > > I agree with what Kevin has written, there should be a way to > distinguish several cases of forward / backward, those where you can walk > in both directions but only one is signposted, > > > We discussed this already in april of this year: > https://lists.openstreetmap.org/pipermail/tagging/2019-April/044975.html > > To summarize: some people preferred to no use "oneway=yes" on relations to > indicate a trail can be hiked in both directions, but only one is > signposted. This was because oneway implies a legal restriction and to > avoid confusion. We then came up with the new key signed_direction= for > this purpose. For lack of a better solution, the order of the members of > the relation is used to determine in what direction the hike is signposted. > I made the wiki page ( > https://wiki.openstreetmap.org/wiki/Key:signed_direction) and the tag has > been used since then by other mappers ( > https://taginfo.openstreetmap.org/keys/signed_direction) > ___ > 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 - hiking_trail_relation_roles
I wiould mark the route oneway=yes to indicate oneway signposting, then oneway:foot=yes (or whatever is in use to indicate an access restriction on a way) on the ways where it is actually forbidden. I would not take oneway=yes on a route relation to indicate legal restriction on its members. Vr gr Peter Elderson Op za 7 dec. 2019 om 13:22 schreef Mateusz Konieczny < matkoni...@tutanota.com>: > There are some hiking routes > signposted with allowing travel in one > direction and forbidding in the opposite. > > > 7 Dec 2019, 13:04 by pelder...@gmail.com: > > Cannot be legal for a pedestrian route, I think. So practical. > > Mvg Peter Elderson > > Op 7 dec. 2019 om 10:53 heeft Martin Koppenhoefer > het volgende geschreven: > > > > sent from a phone > > On 7. Dec 2019, at 04:36, Warin <61sundow...@gmail.com> wrote: > > If oneway=yes is placed on a route relation then any excursions and > appropriate approaches will have to be separate relations. > > > > is it a legal restriction or a practical one if placed on a route relation? > > > 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 > > ___ > 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 - hiking_trail_relation_roles
Cannot be legal for a pedestrian route, I think. So practical. Mvg Peter Elderson > Op 7 dec. 2019 om 10:53 heeft Martin Koppenhoefer > het volgende geschreven: > > > > sent from a phone > >> On 7. Dec 2019, at 04:36, Warin <61sundow...@gmail.com> wrote: >> >> If oneway=yes is placed on a route relation then any excursions and >> appropriate approaches will have to be separate relations. > > > is it a legal restriction or a practical one if placed on a route relation? > > > 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 - hiking_trail_relation_roles
you could define oneway=yes to be applicable to the main route. Sounds logical to me, i think most hikers would assume that. I think long excursions, branches and alternate routes are better maintained as separate relations. It's a separate discussion if these all need to be put into a 'collection' route relation. Mvg Peter Elderson > Op 7 dec. 2019 om 04:36 heeft Warin <61sundow...@gmail.com> het volgende > geschreven: > > >> On 07/12/19 14:09, Andrew Harvey wrote: >>> On Sat, 7 Dec 2019 at 13:07, Martin Koppenhoefer >>> wrote: >>>>> On 7. Dec 2019, at 01:51, Peter Elderson wrote: >>>>> >>>> I think a simple oneway=yes on a hiking route relation could say it's >>>> signposted for one direction. >>> >>> >>> I would prefer being more explicit in the tag name, e.g. >>> sign_direction=forward/backward/both >>> >>> pedestrian_oneway=yes >>> or maybe >>> >>> oneway:foot=yes >> >> Where it's a restriction on the walking path, then oneway=yes on the way, >> when it's a restriction on the route a oneway=yes on the route is the way to >> go. > > If oneway=yes is placed on a route relation then any excursions and > appropriate approaches will have to be separate relations. Meaning there will > have to be a super relation to combine them... > > > ___ > 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 - hiking_trail_relation_roles
And, I would interpret the route direction for pedestrians as a suggestion, not an access restriction or physical restriction. Mvg Peter Elderson > Op 7 dec. 2019 om 04:11 heeft Andrew Harvey het > volgende geschreven: > > > On Sat, 7 Dec 2019 at 13:07, Martin Koppenhoefer > wrote: >>>> On 7. Dec 2019, at 01:51, Peter Elderson wrote: >>>> >>> I think a simple oneway=yes on a hiking route relation could say it's >>> signposted for one direction. >> >> >> I would prefer being more explicit in the tag name, e.g. >> sign_direction=forward/backward/both >> >> pedestrian_oneway=yes >> or maybe >> >> oneway:foot=yes > > Where it's a restriction on the walking path, then oneway=yes on the way, > when it's a restriction on the route a oneway=yes on the route is the way to > go. > > We already have a well documented and accepted way to tag conditional > restrictions via > https://wiki.openstreetmap.org/wiki/Conditional_restrictions. So no need for > a new tag, oneway:foot=yes/no is the way to go. If you want to be explicit > that's fine, but I think oneway=yes on a highway=footway,path already implies > it's oneway for pedestrians. > ___ > 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 - hiking_trail_relation_roles
Martin Koppenhoefer : > On 7. Dec 2019, at 01:51, Peter Elderson wrote: >>> >> I think a simple oneway=yes on a hiking route relation could say it's >> signposted for one direction. > > I would prefer being more explicit in the tag name, e.g. > sign_direction=forward/backward/both Hm... sign direction for pedestrians is assumed both, if it's one way I would say forward is the sign direction. There is no extra information in this tag. > pedestrian_oneway=yes When applied to a walking route, "pedestrian" is implicit. > or maybe > > oneway:foot=yes Same comment. > > would be more in line with what we already have: > https://taginfo.openstreetmap.org/search?q=oneway oneway is mostly applied to ways, where pedestrian is not implied. For a route, the mode of transport is implied, and the tag is applied to the route, not to specific ways. > __ > 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 - hiking_trail_relation_roles
I have actually come across 1 instance where a pedestrian should not go in the opposite direction, and markings were actually different for the directions. Most hikers would simply use the opposite route section for both directions. That is to say it's a very rare exception. Completely different from cycling routes, which tend to have many sections where the route directions use different sets of ways. I think a simple oneway=yes on a hiking route relation could say it's signposted for one direction. Mvg Peter Elderson > Op 7 dec. 2019 om 01:12 heeft Martin Koppenhoefer > het volgende geschreven: > > > > sent from a phone > >> On 6. Dec 2019, at 19:29, Janko Mihelić wrote: >> >> I think the "forward" and "backward" don't belong in a role of a relation. >> Oneway=yes on a way should be enough > > > oneway is generally not considered to apply to pedestrians. > I agree with what Kevin has written, there should be a way to distinguish > several cases of forward / backward, those where you can walk in both > directions but only one is signposted, and those where you actually can’t use > it bidirectionally (e.g. it is too narrow and too much traffic) > > 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 - hiking_trail_relation_roles
Andy Townsend : > Michael Behrens: > > > There is no unique way to tag roles in hiking route relations > > I'd suggest making it clear that that table is currently for way members > only - it doesn't mention node members (start, end, marker, etc.). This > may be deliberate, or you just haven't expanded it yet, but I'd definitely > mention node members. > > Also, i guess backward and forward roles are for ways only, the other roles are more suited for relation members. Or not? Could I enter all the ways of a 3 Km medieval castle excursion to a viewpoint into the hiking relation holding the ways of the main route, each with the 'excursion' role? I think this should be explicit. It seems to me that use of these roles leads to relations containing non-contiguous trails. I would call those relations collections rather than routes. Processing non-contiguous routes presents extra challenges for processing such as exporting routes and making elevation profiles. __ > 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 - (contact:phone)
Volker Schmidt : > On Wed, 4 Dec 2019 at 13:42, Sören Reinecke via Tagging < >> tagging@openstreetmap.org> wrote: >> >>> This proposal is different. It's about deprecating the `phone` key. >>> >> > (For deprecating a key that is used 1 504 275 times with another one with > the same meaning you need very very good reasons) > I believe in effect it would deprecate deprecation > ___ > 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] Barrier=berm
How about use=* /* Answers the question: what's the use of this thing? Well, the use=* Fr gr Peter Elderson Op do 28 nov. 2019 om 09:53 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > Am Do., 28. Nov. 2019 um 01:23 Uhr schrieb Graeme Fitzpatrick < > graemefi...@gmail.com>: > >> A berm, in modern usage, does indeed refer to any number of broadly >> similar concepts, in that it is (usually) a simple pile of dirt, either >> bare, or covered with grass. >> >> So how about changing the definition to: >> " A *Berm <http://en.wikipedia.org/wiki/en:Berm>* in modern usage, is a >> raised barrier (usually made of compacted earth, either bare or grass >> covered) separating two areas. It can have many applications, including as >> a defensive fortification line, a protective barrier, a border/separation >> barrier or in industrial or sporting settings". >> Is that better? >> >> > > I believe we should define the tags according to their meaning. If I get > this right, a berm is defined through their shape, is describing a physical > characteristic. Therefor the definition should not be about the > applications / function. For the function we should add additional tags if > deemed useful by the mapper. So there would be a tag to say it is a berm > (man made earthwork of certain shapes), and another one that says there is > a fortification line, or a protection for a shooting range, or whatever. > > > Jan Michel wrote: > >> - We should have a defined way to tag the purpose of the berm - e.g. >> berm = noise_barrier >> > > > along the reasoning above, I would expect the key "berm" to describe a > type of berm. I am not an expert for earthworks, but I am pretty sure there > will be subtypes of berms describing maybe physical characteristics or > other constructive details (e.g. how it was built, if there is > reinforcement, etc.) > Therefore functional characteristics like "this is there for noise > protection" should go into another tag (would have to discuss what makes > sense). > > 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] How to correctly name a forest
Sound like a magical infinite multipolygon to me. Mvg Peter Elderson > Op 28 nov. 2019 om 00:06 heeft Martin Koppenhoefer > het volgende geschreven: > > > > sent from a phone > >> On 27. Nov 2019, at 23:41, Mateusz Konieczny wrote: >> >> Tree covered areas are easy, but we are >> missing something like place=forest > > > +1, once I thought we could use „natural“ for this, but it didn’t get > traction... > > A node will not be sufficient, because the typical situation is a forest > within a forest within a forest within a forest within... > > 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 - footway=link
Looks good. I think mapping the lowered kerb separately for simple exits is a bit overdone. Vr gr Peter Elderson Op za 23 nov. 2019 om 12:28 schreef Allroads : > I worked out a visualisation image. > From the situation I linked in my earlier post. > > https://i.postimg.cc/jqJSxT1w/service-crosssing-text.png > > > Allroads. > > ___ > 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 - footway=link
+++1 I map a lot of walking routes. Walking route relations use many virtual footways. In the old days, when sidewalks were seldom mapped, you entered the road. Now many sidewalks are available as pedestrain ways or areas, but these do not form a complete linked network, so you often have to link to roads or cycleways. Over pedestrian areas you create a footway or path with the same surface as the area. Connecting two footways over a road where no visible crossing existed, likewise. I have even come across the bus stop example, when mapping a hiking route with a bus transfer in it, through a cars-only tunnel. These links are supposed to show up in route maps, but should not render on general maps. Currently they do render on general maps, which creates a false impression of an actual feature. Quality of the map would improve by not showing the virtual link paths. I would be happy to implement the link thingy in all the longdistance walking routes I co-manage, next time I do an integrity check. Adding the link tag to all the fake footways/ paths. Talking about ca 50 hiking routes between 100 and 500 Km in length, in Nederland. One each week, finished in a year. I do hope the proposal passes quickly. FrGr Peter Elderson > Op 23 nov. 2019 om 02:36 heeft Nick Bolten het volgende > geschreven: > > > I'm a big fan of this proposal and like others I think it could be useful in > many scenarios. Expansion beyond connecting sidewalks to streets would be > great! > > I would propose that under an expansive definition it be thought of this way: > a "footway link" is a path connecting pedestrian-accessible ways that is not, > itself, a centerline of a designated physical pedestrian space. > > Examples: > > 1. Connecting a dead-end sidewalk to the street (already in the proposal): > real pedestrians may want to walk on a sidewalk that only extends partially > down a street, then revert back to walking on the side of a street. A footway > link acknowledges this transition and maintains network connectivity. > > 2. Connecting orthogonal footways to the street, even when there's no > designated footway (the steps example): Similar to the first example, > pedestrians may want to fall back on the street network after transitioning > from steps, or we may want to maintain connectivity for routing software that > makes primary use of streets without having "fake" pedestrian ways connected > to the street: steps connecting directly to a street across a sidewalk, a > footway from a park doing the same, etc. > > 3. Transitioning from a sidewalk to a crossing, where both are separately > mapped: we've often run into the challenge of saying 'what is this thing?' > when mapping highway=footway, footway=crossing, highway=footway, > footway=sidewalk, and kerb=* to describe pedestrian spaces. It's that short > path that extends from the sidewalk to the street. It isn't really a > sidewalk, even though it's on top of one. It isn't really a crossing, because > you're still on the sidewalk at that point. It's a link between footways! > This would be helpful for QA and increased mapping: when a footway=link meets > a footway=crossing, we can ask for mappers to add kerb=* using software like > StreetComplete. > > 4. Plazas. While it is possible to extract many plausible paths through > pedestrian area features, there is value in simply mapping the most direct > paths and not requiring data consumers to become intimately familiar with > skeletonization algorithms or robotics pathfinding. Mapping canonical paths > through plazas as links allows both options: they can be ignored (as they are > acknowledged to be connections rather than distinct paths) or consumed > directly. > > 5. Short paths to building entrances from sidewalks, other footways. These > are often not truly a designated footway, just a path from the sidewalk > centerline to the building's entrance, but they can still be complicated: > they might have steps along them, or have a unique geometry due to fencing or > walls. A link will assist in mapping this accessibility information and > remove confusing data from the map. > > 6. Short paths that deviate slightly from centerlines to make use of > facilities, but are still related to those other footways. For example, there > may be a single clear way to navigate from a sidewalk centerline to a bus > stop that is not the canonical sidewalk centerline. It's a path on the > sidewalk that could be worth describing (for example, street furniture may > cause it to have a narrow passable width), but it's not itself the primary > sidewalk way. > > Thanks for proposing this! It really scratches an itch. > > Nick > >> On Mon, Nov 18, 2019
Re: [Tagging] Additional detail of Levee mapping via embankments
Messages are sent with Reply-To: "Tag discussion, strategy and related tools" So simple reply should be enough, that's what I do and it works. Fr gr Peter Elderson Op do 14 nov. 2019 om 11:46 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > > > sent from a phone > > > On 14. Nov 2019, at 04:08, John Willis via Tagging < > tagging@openstreetmap.org> wrote: > > > > Sorry, I am continuing to have trouble properly replying to the tagging > group, it keeps defaulting to the individual. > > > you have to “reply to all” > > @list-admin maybe this setting could be changed? Replying to the list > should be the default for a mailing list > > 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] Deprecating mini_roundabout
I would say no, because the roundabout signs are not there. It's just an ordinary crossing with traffic control signage and markings. Vr gr Peter Elderson Op vr 25 okt. 2019 om 10:38 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > There was once a normal crossing of 4 ways, which has been converted into > a "normal roundabout" by putting up a set of arrow signs on a single pole > in the centre (i.e. it was mini wrt dimensions, but not because it was not > traversable). As this didn't work out (no room for bigger vehicles to turn) > they removed the centre pole hence making it a true mini-roundabout. For > some reason this summer they removed the roundabout signs but kept the > give-way signs on all ways and made 2 of the ways oneway streets, effective > keeping the mini-roundabout situation. Is this still a mini-roundabout now? > > Here's the situation: > https://www.openstreetmap.org/node/2542833090 > > this was the recent situation after the central obstacle was removed and > before the roundabout signs were removed: > > https://www.google.com/maps/@41.8592771,12.4807523,3a,75y,350.02h,90.94t/data=!3m7!1e1!3m5!1sczuox86d1I8lGASn0YgzuQ!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3Dczuox86d1I8lGASn0YgzuQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D12.696002%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192 > > 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] Deprecating mini_roundabout
https://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout says > The tag junction <https://wiki.openstreetmap.org/wiki/Key:junction>= > roundabout is *used only on road intersections where traffic on > the roundabout <https://en.wikipedia.org/wiki/Roundabout> has right of way* > . > That is, the roundabout itself should be free from all intersection > controls including traffic signals, stop signs or stop markings, give-way > (or yield) signs or give-way markings. However there exists exceptions in > some roundabouts in some cases where there's a special service way passing > through the island, reserved to buses/tramways/emergency vehicles (which > will have priority to the normal traffic, and for which there may be > traffic signs requiring vehicles on the ring to give the way; in normal > times these giveways and traffic signals are off). > Where traffic does not have right of way, this is a rotary > <https://en.wikipedia.org/wiki/Traffic_circle> (also called traffic > circle). The tag junction > <https://wiki.openstreetmap.org/wiki/Key:junction>=circular > <https://wiki.openstreetmap.org/wiki/Tag:junction%3Dcircular> should be > used on rotaries In the Netherlands, all roundabouts are tagged junction=roundabout, even though without any controls traffic on the roundabout would legally have to give way to traffic coming from the right, entering the roundabout. I'm not vary confident that mappers would want to change the mapping just because the traffic code has changed somewhere in the past. Nobody here knows the word rotary for a roundabout. In practice, all roundabouts have traffic controls. Small ones just have shark's teeth, that's a legal priority control. I move to make this this restriction less strict: if there is traffic control by static signs or markings, it's also a junction=roundabout. This is visibly verifiable by any mapper, and would retain the requirement of priority for traffic on the roundabout over traffic entering the roundabout. Fr gr Peter Elderson > > ___ > 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] Deprecating mini_roundabout
> > Countries have their own legislation. Poland apparently has things that > look like mini roundabouts but follow the regulations of "ordinary" > roundabouts. Netherlands has many mini roundabouts AND they follow the regulations of ordinary roundabouts. However, those are the same as for other junctions. So according to the wiki, these roundabouts and mini-roundabouts should not be tagged as roundabouts but as circular junctions, because no priority is implied. Nevertheless these rotaries are massively tagged as roundabouts, and lots of junctions wih a dot or circle in the middle as mini-roundabouts. Because that's what they look like, and that's what they are called: "rotonde" en "mini-rotonde". So far I see no compelling reason to change it. Regardless of legal issues and signage, navigation systems should not advise u-turns on narrow junctions including narrow mini-roundabouts. I guess that is why navigation systems keep telling me to "try and turn around", without telling how and where. Fr gr Peter Elderson Op wo 23 okt. 2019 om 15:58 schreef Paul Allen : > On Wed, 23 Oct 2019 at 14:35, Jez Nicholson > wrote: > >> AFAIK the traffic regulations are: >> 1. You should *avoid* doing a U-turn at a mini roundabout because there >> isn't much room to turn in, and people might not be expecting it. You are >> still allowed to do so. >> 2. *only* drivers of long/large vehicles may only drive over it. Everyone >> else has to drive round the roundabout as usual >> > > Highway code rule 188: > >> *Mini-roundabouts.* Approach these in the same way as normal >> roundabouts. All vehicles *MUST* pass round the central markings except >> large vehicles which are physically incapable of doing so. Remember, there >> is less space to manoeuvre and less time to signal. Avoid making U-turns at >> mini-roundabouts. Beware of others doing this. >> *Laws RTA 1988 sect 36 & TSRGD regs 10(1) & 16(1)* >> > >> Point 1 should affect routers to discourage them from suggesting a >> u-turn, but not prohibit it. >> > > Depends how you interpret "avoid." I am not a lawyer. If I wrote a > router, I'd err on the > side of caution here: don't suggest a U turn as a feasible route, don't > allow a user to enter > a route with such a U turn. > > I believe the same would be true for any country. >> > > Countries have their own legislation. Poland apparently has things that > look like mini > roundabouts but follow the regulations of "ordinary" roundabouts. > > Therefore, it is worth knowing whether it is a mini or standard roundabout. >> > > Absolutely. > > -- > 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] Deprecating mini_roundabout
Can you provide the legal basis for that? So far I have only found documentation saying there is no such legal restriction in the UK. Fr gr Peter Elderson Op wo 23 okt. 2019 om 15:10 schreef Philip Barnes : > > > On Wednesday, 23 October 2019, Florian Lohoff wrote: > > On Wed, Oct 23, 2019 at 12:42:27PM +, Philip Barnes wrote: > > > It is not just a British thing, I have encountered many when driving > in France. > > > The rules and usage are the same as in the UK. > > > The other rule that makes them different to other roundabouts is that > you should not use them to turn around, do U turns. > > > > So what is the difference then? > > > You can enter a normal roundabout, do 360 degrees and then be traveling in > the opposite direction. It is a common and useful navigation decision. Turn > restrictions are often used to force that behavior. > > You should not do that with a mini roundabout. > > > Phil (trigpoint) > > > > What i know learned: > > > > - You may traverse the center > > - No more than 4 exits as left/right/straight on wont work > > - You dont expect nav aids to be "2nd exit etc" but a "turn left at" as > > the navaids are like a junction. > > > > Anything else? > > > > Flo > > -- > > Florian Lohoff f...@zz.de > > UTF-8 Test: The ran after a , but the ran away > > > > -- > Sent from my Sailfish device > ___ > 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] Deprecating mini_roundabout
This does not seem te be a legal restriction. NB In Nederland, roundabouts and miniroundabouts are legally no different from any other junction. Signs govern the right of way / yield obligations. Without specific giveaway signs the rule is: give way to traffic coming from the right. This would mean: yield to traffic entering the roundabout. Of course most roundabouts have the road signs or there would be a lot of incidents, but mini roundabouts often do not. So in that case they are just guidance points. Main point: there is no difference. I guess this means we have no roundabouts, just rotaries. Most of these are tagged as roundabouts anyway. U turns are allowed unless there is a traffic sign saying you can't. In short, mini-roundabouts are just regular junctions in Nederland. Fr gr Peter Elderson Op wo 23 okt. 2019 om 11:26 schreef Philip Barnes : > There is also the rule that you should not do U turns at mini roundabouts, > so it is important that mapping retains this important distinction. > > > ___ > > > Tagging mailing list > > > Tagging@openstreetmap.org > > > https://lists.openstreetmap.org/listinfo/tagging > > > > > > > -- > Sent from my Sailfish device > ___ > 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] Cycling relation misuse
I compare it with the Via Francigena in Italy. That route is very well signposted, but even if it were not, you would see signs of its existence and importance in road names, milestones, names and signs of dwellings and café's along the way. There are self-registration points on the way, resting places with a pilgrim sign. And yes, all the locals know it and will point you to it. You'll get complete local history lectures with it, which I would not record in OSM though :) . Vr gr Peter Elderson Op ma 14 okt. 2019 om 09:38 schreef Warin <61sundow...@gmail.com>: > On 14/10/19 18:28, Peter Elderson wrote: > > brad: > >> There are several variations and gpx tracks available on the net for the >> great divide route. There are also many websites which discuss the route >> and show maps. It's in the public domain. >> >> > I've looked at the info for the Great Divide MTB-trail without any prior > knowledge. > On the one hand I think, if there's nothing on de ground don't map it. > On the other hand, if it's a fixed and well kept trail known to all, I > imagine mtb maps showing all kinds of mtb-trails except The Big One that > everybody knows. If I were an MTB'ist, I would probably disxcard OSM as > unusable, because it doesn't even give the biggest MTB-route on the planet! > > > If you ask local where it is a fair proportion would direct you to it? > > > ___ > 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] Cycling relation misuse
brad: > There are several variations and gpx tracks available on the net for the > great divide route. There are also many websites which discuss the route > and show maps. It's in the public domain. > > I've looked at the info for the Great Divide MTB-trail without any prior knowledge. On the one hand I think, if there's nothing on de ground don't map it. On the other hand, if it's a fixed and well kept trail known to all, I imagine mtb maps showing all kinds of mtb-trails except The Big One that everybody knows. If I were an MTB'ist, I would probably disxcard OSM as unusable, because it doesn't even give the biggest MTB-route on the planet! I would hope that there are some things along the track dedicated to the route. A "start here" sign, parking space for starting a section, arrangement of stones, sticks, adaptations e.g. to make a crossing possible, anything that shows it's a route. I can't imagine there are no visible signs of a trail at all. Then that would be my excuse to map it! > ___ > 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] Cycling relation misuse
Netherlands usage is: the route must have some physical representation on the roads. Preferably waymarked all the way. But long routes tend to use local/regional/national sections as parts, so the waymarking does not have to be the same everywhere. Also, some routes are scarcely or even barely signed, still, when zooming out they are clear trails. Personally, I would even allow routes which consist of e.g. a list of places to visit, with a sign at the central square or the main church naming and showing the route. Some sections of Jacob’s trails and other european internation routes work like that. But, just documentation on a website or a book describing a route: I would oppose that. Mvg Peter Elderson > Op 12 okt. 2019 om 04:27 heeft John Willis via Tagging > het volgende geschreven: > > > >> On Oct 12, 2019, at 1:28 AM, Phyks wrote: >> >> Hi, >> >> I've found similar issues in France recently. Cycling routes is too >> broad and diverse and covers various realities. From a rendering >> perspective (disclaimer: I'm one of the maintainer of the new CyclOSM >> rendering style, https://cyclosm.org), it is very often a nightmare to >> try to figure out which one are worth rendering and which ones are just >> "tag to render". > > > Similar to how bus routes are laid over existing road infrastructure, I think > there should be a big distinction between the paths/crossings/roads that are > assembled to make a cycling “road", and some route that people have come up > with just for exercising that is just some generic road in rural area people > go touring on. > > - Cycling roads/routes for travel/transportation with some kind of documented > status with the government. > > - MTB routes, usually using off-road ways & infrastructure - documented by > the maintainer of the route, whoever that is. > > - roads used by cyclists for exercise/racing, with no documentation or > signage - usually shared via online route-sharing sites. > > if you are making a map of the cycling routes available, I would assume the > first category is the most important, and possibly the only one that should > be prominently rendered. > > similar to how we render roads, the prominence of motorways pales to the > prominence of lesser roads. Please include them, but we would need tagging > to show the purpose of the route, beyond “network” or what super-relation > they belong to. > > This might be difficult, as the usage probably vary from region to region: > MTB routes in Japan are negligible, and dedicated cycling roads abound. > Whereas in San Deigo, there are zero “cycling roads” that are maintained by > the government, and probably a lot of documented MTB routes in the wilderness > parks. > > but documenting & rendering any route that a cycle club enjoys cycling on the > weekend? unneeded. a motorcycle club’s favorite route in the mountains is > unworthy of a route relation as well. > > OSM is not an online route-sharing site. > > here is a “Nikko Loop” route made by some cyclist who enjoys cycling. > > https://ridewithgps.com/routes/31059198 > > This is the job of this other private website (ridewithgps.com) - document > and share routes for cyclist users. But Nikko City has no documentation for > such a route, and shouldn’t be included in OSM. > > > Javbw > > ___ > 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] Divided highways, and not so divided highways, one way or two
But where pedestrian crossing is not allowed at all, as in the case I described, two ways tagging does not give this routing problem. These roads are not for pedestrians, there is no sidewalk, and if there is a separate footway or cycleway it is physically separated and cyclists/pedestrians will have to find the nearest crossing, as does the router. NB I am not pleading one way or the other. I just think there are cases where two-way tagging is a plausible and an acceptible solution, even when there is no physical vertical barrier. Oneway tagging might suggest crossing possibilities where in fact crossing is not feasible, even dangerous. That would be worse for a router than the opposite, because it might put people in danger. Routing a detour is the lesser evil. Mvg Peter Elderson > Op 11 okt. 2019 om 21:05 heeft Markus het > volgende geschreven: > >> On Fri, 11 Oct 2019, 11:21 Snusmumriken, >> wrote: >> > >> That tag is about lane changing, I don't see how it could be applied to >> my example > > > If i understand the wiki page correctly, > > lanes=2 > lanes:forward=1 > lanes:backward=1 > change:lanes:forward=not_left > change:lanes:backward=not_left > > would mean that on both lanes it isn't allowed to turn left onto the lane of > the oncoming traffic. > > And for the case i misunderstand that tag, we can invent a new tag. Splitting > the road into two parallel ways isn't the only possible solution. > >> My assumption is that pedestrian routing engine would stick to >> sidewalks and crossings and not to tell the pedestrian to cross a >> street where there is no crossing. The individual pedestrian can of >> course make up his own mind what legal/physical risks are acceptable to >> save a bit of time > > > As Kevin already pointed out, there are many places without pedestrian > crossings. Therefore pedestrian routing wouldn't work where a road with > painted lane separation is mapped with two ways. > > I wish you all a nice weekend > > Markus > ___ > 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] Divided highways, and not so divided highways, one way or two
Then you wouldn’t tag separate carriageways on that particular way. In my country, lots of roads have carriageways separated by two lines with a green paint band of 1 m in between. I understand this is a type of european lining. Sometimes there is grass in between for a stretch, or vertical barrier. Roundabouts are the favoured kind of crossings, the green band usually widens there and gets stripes, sometimes kerbs and grassy areas, ideal for placing giant billboards or artistic objects. I would not hesitate to map these as two ways. The sections approaching roundabouts already are mapped separate. Mvg Peter Elderson > Op 11 okt. 2019 om 15:27 heeft Kevin Kenny het > volgende geschreven: > > On Fri, Oct 11, 2019 at 5:21 AM Snusmumriken > wrote: >> My assumption is that pedestrian routing engine would stick to >> sidewalks and crossings and not to tell the pedestrian to cross a >> street where there is no crossing. The individual pedestrian can of >> course make up his own mind what legal/physical risks are acceptable to >> save a bit of time > > You surely don't live in my neighbourhood! Aside from the fact that > there are no sidewalks on the residential streets, I don't think there > is any place where the tertiary road to the north has a marked > crossing. The routing engine that you imagine would say, "you can't > get there from here." I admit that the town isn't pedestrian-friendly, > but I still walk to work daily. > -- > 73 de ke9tv/2, Kevin > > ___ > 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] Divided highways, and not so divided highways, one way or two
> Op 11 okt. 2019 om 11:22 heeft Philip Barnes het > volgende geschreven: > > Not just the driver. Routing software can be used to determine which vehicle > can give the quickest response. > > Phil (trigpoint) I would never trust OSM data for emergency routing or any purpose requiring high reliability, unless I had complete control and quality assurance of the data. And since basic setup of OSM is that anyone can change data at any time, I can be sure I don’t have guaranteed reliability. > ___ > 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] Divided highways, and not so divided highways, one way or two
Why would it be inferior? Visually, you mean? Or would navigational problems arise? There already exist roads with some parts physically separated halves and other parts combined halves, does that give problems? Mvg Peter Elderson > Op 10 okt. 2019 om 15:01 heeft Snusmumriken > het volgende geschreven: > >> On Thu, 2019-10-10 at 08:38 +0200, Frederik Ramm wrote: >> Hi, >> >> DWG has been asked to mediate in a user dispute in Germany where a >> local >> mapper has chosen to represent a busy four-lane primary highway (two >> lanes in each direction, and a double continuous line painted in the >> middle which is physically possible but legally not allowed to >> cross). >> >> Other mappers object to this saying that it violates the rule that >> there >> must be some sort of physical division to allow that form of mapping. >> >> The original mapper claims that using two separate oneway=yes ways is >> clearer and easier, as it does away with the need for turn >> restrictions >> at junctions. Other mappers claim that the two-separate-way mapping >> is >> violating rules and that OSM will soon become unusable if everyone >> maps >> how they want. >> >> The question is basically two-fold; one, what are the established >> standards and rules concerning this situation, > > I don't think that there are any rule that would say "legal separation > => shared way". I also think that such a rule would lead to an inferior > map. > > > ___ > 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] Draft: landuse=open_defecation vs landcover=open_defecation vs open_defecation=yes
Defecation is a landuse. The implied landcover would be landcover=shit Mvg Peter Elderson > Op 23 sep. 2019 om 18:38 heeft Bob Kerr via Tagging > het volgende geschreven: > > Hi, I have a last draft for tagging open_defecation > > See > > https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dopen_defecation > > However I came across landcover > > https://wiki.openstreetmap.org/wiki/Landcover > > landcover=open_defecation > > Which I think is more appropriate because that is what it is, it is not an > officially sanctioned landuse. > > Originally it was open_defecation= yes > > Could I have a quick vote on which you prefer before it becomes a proposal > > Many thanks > > Bob > ___ > 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] mesh bicycle network
In NL node networks all node2node routes are route relations. Then all the relations and the nodes are added to the network relation, where the network:type (i.e. the setup/system/rules), the network name, operator, website etc are tagged. Currently, the network relation for node networks is used only for maintenance en checking network integrity. I think the network in Bremen is a preference route system. Vr gr Peter Elderson Op do 12 sep. 2019 om 22:49 schreef Hubert87 via Tagging < tagging@openstreetmap.org>: > To summarize: > - (highway) Use lcn=yes on the highway; (my Idea) maybe with some more > Information about the network like lcn:operator=*, lcn:ref=* or similar. > - (route-relation) split up the network into smaller relations going > from guidepost to guidepost. Seems very complicated, also to query/get > the entire network. > - (network-relation) get a new value for network:type=* , maybe > guidepost_network. > > I still have a slight preference toward the network-relation. It seems > very similar to the node-network from NL and imho should be tagged > comparably. > > However, most import to me is to keep the information about the network > character somehow. A simple lcn=yes won't do that. > > Yours > Hubert87 > > > ___ > 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] mesh bicycle network
I think it makes sense to map preference routes as route relations, same as node2node routes within node networks. I am not a fan of network relations if they are just collections of elements, but if the information about how they are organised and used is also present and verifiable by survey (which is the case in the present example) it's not wrong and could be useful for maps, planners and routers. How to use the elements in a network can be tagged by a suitable value of network:type. Currently, network_type=node_network is used, the system is increasingly adopted for all recreational transport modes. If many cities use verifiable preferential route networks, a suitable value for network:type could be added, making the route relations and network relations a system reflecting actual use rather than just collections. A network relation without the node2node or signpost2signpost relations makes no sense to me. The signposts and arrows denote actual routes, that is the basis of the system. Just adding lcn=yes to the ways loses the information about the routing/network system(s) they are part of. If that's fine, no problem. If people want to map the routes and maybe the network, I think it's OK too. We have the means. Fr gr Peter Elderson Op do 12 sep. 2019 om 12:01 schreef Volker Schmidt : > I see similarities of this approach with the hiking paths of the alpine > clubs, but with the important difference that the routes do not have a > reference. > And it's very similar to a node network, except that the nodes are not > numbered. > It's a 1:1 copy of the road network signposting (and please allow the > comment, has the same drawback in the sense that is not helpful to people > who are not familiar with the area and don't know the names of the places > and their relative positions) > > I fear the only sensible thing to do is to put the lcn and REF on each > way, but no relation, and map the signposts (even if there is no routing > software at the moment that makes use of this information, as far as I > know). > Not the best solution, but the signposting in this way does not work well > either for the end user (talking from experience). > > On Thu, 12 Sep 2019 at 11:21, Janko Mihelić wrote: > >> I don't think this is good mapping. Firstly, this is not a route. A route >> is something that gets you from one place to another. This is a network of >> routes, and there is a tag for it, type=network[1] But this type of a >> relation breaks the "Relations are not Categories" rule [2]. That's why I >> think this network relation should be broken up into route relations with >> the appropriate network tag. >> >> If this is allowed, then what stops someone from making a "Bicycle routes >> in Germany" relation ? >> >> >> [1] - https://wiki.openstreetmap.org/wiki/Relation:network >> [2] - >> https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories >> >> čet, 12. ruj 2019. u 11:05 Martin Koppenhoefer >> napisao je: >> >>> >>> >>> sent from a phone >>> >>> > On 12. Sep 2019, at 10:49, Peter Elderson wrote: >>> > >>> > If there is agreement that this actually is something worth mapping, I >>> don't see a problem there. >>> >>> >>> this is how wikipedia works, in OpenStreetMap you do not need approval >>> of others that something is “worth” mapping, the osm question is whether >>> something is verifiable. >>> >>> >>> 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 >> > ___ > 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] mesh bicycle network
I would say it is a system of preferential cycleroutes to different destinations. It resembles the system of preferential truck routes in Amsterdam. It is a system, and it's visible on the ground. The arrow signs create a route to the next signpost in the chosen direction. If there is agreement that this actually is something worth mapping, I don't see a problem there. The network:type=* tag creates the option to add network-systems for all transport modes. If a clear value for this network:type can be agreed upon, I see no problem there either. That's my own opinion. Since the Dutch route mappers came up with the network:type tag to explicitly map network systems (i.c. node_network), and since we have discussed how to tag a preference route system for trucks in Amsterdam last year, I will ask on the Dutch OSM forum how they feel about this idea. Fr gr Peter Elderson Op do 12 sep. 2019 om 00:04 schreef Hubert87 : > Hi, > > i have stumbled over the post about rcn and cycling node networks and > was wondering if you guys might have a proposal for primary bicycle > route mesh network relation(s) like this one > https://www.openstreetmap.org/relation/3585265, which is in Bremen, > Germany. > > It is neither a cycling node network nor a classical bicycle route but a > set of > guideposts(https://www.mapillary.com/map/im/AlXYW3arx59dkSlruUsWjg) > showing poi destinations and distances completed with addition smaller > signs (https://www.mapillary.com/map/im/9pqoiH4eH4o7Ieh6IXRnfg) in > between guideposts pointing in the right direction. > > All classical bicycle routes seem to be part of this network, but it > contains more routes. Additionally these routes do not have a beginning > or end or a closed loops, but are more a kind of mesh like the node > network; except for the nodes. > > Also, as far a I can tell, the main guidepost are sorted into 5 regions > (Nord, Süd, Ost, West, Mitte), which is coded in the small print > (mi=mitte) on the guideposts, as can be seen in the first example picture. > > There is a discussion in the german forum > (https://forum.openstreetmap.org/viewtopic.php?pid=762131) about > deleting these relations and just tagging its highways with lcn=yes. > But I'd really looking for a different solution. > Can someone point me to a possible solution? > > Yours > Hubert87 > > > > ___ > 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] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Sorry for the delay, I meant to post this earlier. My bad! We have discussed the arguments again in the Dutch OSM forum. The Belgium OSM forum did not respond, except for vmarc who took active part in the Dutch forum discussion. The German OSM forum had some positive response but no specific details. They have discussed the same problems earlier. The only new argument from this tagging list was that the key network_type or network:type is not very clear; it does not show what the difference is with the key network. I thought that was a valid point, I thought of two alternatives but mappers thought those were wrongfooting new mappers and that's even worse than confusing them. I am sorry to say that some mappers already had started to add the new tag to cycle node networks even before we reached consensus. The Dutch consensus (with a touch of expert Belgian input and no objection from Germany) is: *We add the tag network:type=node_network to all the junction nodes, to all the node2node route relations, and the node network relation of the node network.* This applies to all recreational node networks: all transport modes, and all geographical scopes. Note that the key is not new. There already was some usage, mainly in Spain, thought it wasn't documented. We had a quick look, it doesn't conflict with our use. When done, rXn in itself is no longer reserved for node networks. Node networks can be separated easily and completely from linear routes. This means tagging regular regional routes (linear routes) will once again be possible in Nederland, Belgium and Germany. We actually have quite a few of those, the are now tagged as national routes even when they are entirely within a particular region. The exception has been undone. I will be happy to answer any questions arising from this. Fr gr Peter Elderson Op di 10 sep. 2019 om 19:49 schreef s8evq : > I see that network:type=node_network has been added to the wiki: > > https://wiki.openstreetmap.org/w/index.php?title=Tag:network%3Drwn=next=1897551 > > https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dbicycle=next=1866174 > > Was there consensus on this in the end? I didn't follow the whole > discussion. > > > On Thu, 29 Aug 2019 16:52:47 +0200, Peter Elderson > wrote: > > > LS > > With the arrival of cycling node networks, the Dutch, German and Belgian > > mappers decided to claim (hijack) the network value rcn for those node > > networks. This exception was copied with the claim of network=rwn for the > > walking node networks. > > > > We are currently discussing in the three communities how to coreect this > > exception and return rcn and rwn to their intended use. To do that, we > need > > another way to identify (members of) a route network as (members of) a > node > > network. > > > > The network values identify transport mode and scope of routes, and these > > "dimensions" also apply to node networks. We do not want to add another > > dimension (configuration type) to the network=* values of routes. > > > > Instead, we are thnking about just adding a tag to identify segment > routes > > as parts of a node network. The nodes themselves do not need this, since > > they ARE nodes and have a xxn_ref tag. > > > > In short, we are thinking to simply add the tag network_type=node_network > > (or network:type=node_network) to the node2node network routes. Nothing > > else has to change, which also means that renderers and data users who > > don't change anything, will not notice anything! But if they want they > can > > make use of the separation and handle node networks different than > non-node > > networks. > > > > Notice that no new key or value is proposed here. If new network config > > types arise, a new value for network_type can accommodate that.The method > > is applicable for all transport modes and geographical scopes. > > > > Thoughts, anyone? What did we forget? Shoot! > > > > Fr gr Peter Elderson > > ___ > > 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] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
We have considered node_network=yes. But other network configurations are already present. We now map two network setups, but the default one (chained ways) is by no means uniform, and we have already seen colour choice networks. So all emerging network configurations would need a separate key. So it's more generic and future proof to use one key with values for different network setups. For now we only want to distinguish node_network from the rest, to free up rXn in Nederland, Belgium and Germany for the intended use. So we propose one value, but we want to facilitate the option for more network setups. We've used network_type because it's an existing key. Very very low usage, though. (network:type is used in one smaller network in Nederland, for a pilot, so that is not regular usage. To be removed if another solution is chosen. Still, network:type usage is higher than network_type) Maybe the key should be network_setup=* or network_configuration=* ? Or the namespaced variants, network:setup=* or network:config=* ? For renderers and other data users the string does not matter very much as long as it's uniquely defined. They need to know for a particular route what setup it's part of, preferably by an attribute of the route itself. A renderer then can decide how to render different network configurations. A node network planner needs to find the node network routes connected to a particular node. The safest way to know which routes to use and which not to use, is by looking at an attribute of the routes. A node network router also needs to distinguish exactly which ways to use, so has the same need. Fr gr Peter Elderson Op do 5 sep. 2019 om 07:00 schreef Warin <61sundow...@gmail.com>: > > On 5/9/19 2:42 am, Richard Fairhurst wrote: > > Peter Elderson wrote: > > The network values identify transport mode and scope of routes, and > these "dimensions" also apply to node networks. We do not want to > add another dimension (configuration type) to the network=* > values of routes. > > Instead, we are thnking about just adding a tag to identify segment > routes as parts of a node network. The nodes themselves do not need > this, since they ARE nodes and have a xxn_ref tag. > > In short, we are thinking to simply add the tag network_type= > node_network (or network:type=node_network) to the node2node > network routes. > > I have a strong interest in this proposal. :) [1] > > If I understand you rightly, a route > likehttps://www.openstreetmap.org/relation/1844941 would get an extra > network_type=node_network tag. Nothing else would change. (Correct me if I'm > wrong.) > > You say "we don't want to add another dimension" but you are effectively > doing that; you're just doing it by adding a new tag rather than adding a > value. That's not _necessarily_ a problem but it would be better done in an > extensible way that might be useful for other tagging scenarios, rather than > special-casing this one scenario. > > We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the > _importance_ of the route. > > What we do not have is a tag to identify the _character_ and _purpose_ of > the route. All bicycle routes (except MTB) get lumped together as a generic > route=bicycle. This is increasingly a problem as routes are devised and > signposted for performance cycling, bikepacking, and so on. For example, > there are two new performance cycling routes in Wales which I'd like to map > (https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be > misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain. > > You're proposing a tag called "network_type", but it's a tag for the route, > and what you're using it to describe is the character and purpose of the > route. (The network is already mapped in the network super-relation.) > > So I'd suggest that instead of network_type=, you add route_type= . > > > 'Type' does not add information. If the key is only to have one value .. why > not use the proposed value as the key? > > node_network=yes/no ? > > > ___ > 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] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Richard Fairhurst : > Peter Elderson wrote: > > The network values identify transport mode and scope of routes, and > > these "dimensions" also apply to node networks. We do not want to > > add another dimension (configuration type) to the network=* > > values of routes. > > > > Instead, we are thnking about just adding a tag to identify segment > > routes as parts of a node network. The nodes themselves do not need > > this, since they ARE nodes and have a xxn_ref tag. > > > > In short, we are thinking to simply add the tag network_type= > > node_network (or network:type=node_network) to the node2node > > network routes. > > I have a strong interest in this proposal. :) [1] > > If I understand you rightly, a route like > https://www.openstreetmap.org/relation/1844941 would get an extra > network_type=node_network tag. Nothing else would change. (Correct me if > I'm > wrong.) > You are correct. > You say "we don't want to add another dimension" but you are effectively > doing that; you're just doing it by adding a new tag rather than adding a > value. That's not _necessarily_ a problem but it would be better done in an > extensible way that might be useful for other tagging scenarios, rather > than > special-casing this one scenario. > We do want to add a new aspect: network configuration. We just do not want to add this new aspect into the network tag, because it already has two aspects in it: transport mode and geographical scope. Therefore we decided to just add the new information independent of the other two. This simply allows us (Nederland, Belgium and Germany) to return to the use of rXn as it was intended. We then no longer need the exception that rXn is a node network in these countries only, and a regular regional route (chain of ways) in the rest of the world. > We currently have the "network=ncn|rcn|lcn" tag which broadly identifies > the > _importance_ of the route. > More specific, it gives the transport mode and the geographical scope, including icn for international cycling routes. Same for hiking, and usage for other transport modes (horseriding, canoe, skating) is emerging, and so are regular (chain of ways) routes and node networks including special node network planners. > What we do not have is a tag to identify the _character_ and _purpose_ of > the route. All bicycle routes (except MTB) get lumped together as a generic > route=bicycle. This is increasingly a problem as routes are devised and > signposted for performance cycling, bikepacking, and so on. For example, > there are two new performance cycling routes in Wales which I'd like to map > (https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would > be > misleading if tagged in the same way as other NCN/RCN/LCN routes in > Britain. > > You're proposing a tag called "network_type", but it's a tag for the route, > and what you're using it to describe is the character and purpose of the > route. (The network is already mapped in the network super-relation.) > That is not the idea. Maybe I wasn't clear. The idea is to add the network setup or configuration in a clear and unmistakeable way. You bring up an interesting point: the superrelation. The superrelations are containers of a mix of route relations and nodes but they don't give how these elements are connected. This is the case for both regular routes (think long distance, international, variants) and node network superrelations. So data users using routes would have to determine membership of a superrelation, then analyse the superrelation to find out whether a route is part of a node network, or part of another type of superrelation. At this time, local walking node networks are merging with provincial walking node networks and regional walking node networks into one big national walking node network with connections and branches to Belgian and German walking node networks. The orginal relatively small local node networks already were very difficult to maintain and to use, but on the cureent larger scale the are unmanageabe and unusable. Adding the information as a tag to the individual network routes solves this problem as well. > So I'd suggest that instead of network_type=, you add route_type= . > > This would achieve the same purpose; be semantically more appropriate; and > be extensible to other routes where "route=bicycle" alone does not > adequately capture the character and purpose of the route. > > I disagree. The information is that the route is part of a particular network setup. This does not alter the route itself. It's not about the character of the route, it's about the configuration of the network it's a part of. > Richard > cycle.travel > > > [1] I believe cycle.tr
Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
I think it's the best AND the easiest solution. Network configuration type is currently not tagged. Nederland, Belgium and Germany decided to use rcn exclusively for the cycle node networks. Later they copied that to rwn for the emerging walking node networks. We now want to correct that, but we also want a clear difference between the network condfigurations. Then renderers and other data users can make the distinction. We have considered using another network=* value. But the transport mode is still in there, as is the geographical scope. So you would need extra values for all combinations of mode, scope and config. If yet another network config type emerges, you will need more network values. Every data user has to decode the values to know what's going on. While what we want is just to indicate that this particular rcn route is part of a node network. This is true for all transport modes (now and future) and for all geographical scopes, now and future. So we came to the solution that it is by far the most effective and at the same time the easiest solution to just add the information that a route is part of a node network in a separate tag. The bonus is that other network systems can be accommodated as well. E.g. some regions and some nature parks in Nederland have a "colour choice network", where you can follow a (self-planned) sequence of signposted coloured routes. The extra bonus of this solution is that currently tagged node network routes need no retagging, just addition of the information that they are part of a node network. This allows renderers and other data users to refine the display or handling of the existing rXn routes. We thought of network_type as a key. This is not a new key, it has some non-conflicting usage. We could introduce a new key as a namespaced variant: network:type=*. If this is still confusing: feel free to suggest better names and values to indicate that a route belongs to a network system of the node variety. Fr gr Peter Elderson Op wo 4 sep. 2019 om 18:33 schreef s8evq : > Why don't you continue to use network=* ? Invent a new value for network= > instead of introducing a new, but confusing tag called "network_type". > > I understand that using network_type would be easier. You just add the tag > to the already tagged node networks that are currently using network=rwn. > > But is introducing a new tag "network_type=" really the best solution? Or > is it the easiest solution? > > On Wed, 4 Sep 2019 16:44:58 +0200, Peter Elderson > wrote: > > > > > > > Mvg Peter Elderson > > > > > Op 4 sep. 2019 om 16:30 heeft Simon Poole het > volgende geschreven: > > > > > > > > >> Am 04.09.2019 um 15:59 schrieb Peter Elderson: > > >> Thanks for the illustrations! > > >> > > >> network=* gives geographical scope (local, regional, national, > > >> international) and transport mode (bicycle, foot, canoe, horse, mtb, > > >> ski, skate, ) > > > You know what I'm going to point out. > > > > > > The redundant coding of transportation kind in the the geographical > > > scope was a mistake, but is a done deed for cycling and hiking. BUT > > > there is no need to propagate repeating the mistake for every other > > > transportation mode, lets just stick with local, regional, national and > > > international these (historically I suspect that the values came from > > > direct tagging on ways, lcn=yes and similar). > > > > I agree with your point. Had I been around, I probably would have voted > not to mix scope and mode in one tag. At the same time, the proposed tag > for network configuration type does not change this, nor does it propagate > it. So I would like to keep this a separate issue, and just talk about how > to separate regular routes from node networks. > > > > > ___ > > > 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 > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Mvg Peter Elderson > Op 4 sep. 2019 om 16:30 heeft Simon Poole het volgende > geschreven: > > >> Am 04.09.2019 um 15:59 schrieb Peter Elderson: >> Thanks for the illustrations! >> >> network=* gives geographical scope (local, regional, national, >> international) and transport mode (bicycle, foot, canoe, horse, mtb, >> ski, skate, ) > You know what I'm going to point out. > > The redundant coding of transportation kind in the the geographical > scope was a mistake, but is a done deed for cycling and hiking. BUT > there is no need to propagate repeating the mistake for every other > transportation mode, lets just stick with local, regional, national and > international these (historically I suspect that the values came from > direct tagging on ways, lcn=yes and similar). I agree with your point. Had I been around, I probably would have voted not to mix scope and mode in one tag. At the same time, the proposed tag for network configuration type does not change this, nor does it propagate it. So I would like to keep this a separate issue, and just talk about how to separate regular routes from node networks. > ___ > 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] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Thanks for the illustrations! network=* gives geographical scope (local, regional, national, international) and transport mode (bicycle, foot, canoe, horse, mtb, ski, skate, ) network_type gives network configuration type (chain of ways; node_network=network of nodes) The network configuration type is applicable to all geographical scopes and all transport modes. By adding this as a separate tag the network=rXn tag is free again for regional routes. This applies in Nederland, Belgium and Germany. In other countries the tag network_type creates the option to register node networks in OSM if they are implemented, without reserving a mode/scope network=XXn tag which may be already in use for regular routes (conform the wiki's about routes). Please feel free to offer other solutions! Fr gr Peter Elderson Op wo 4 sep. 2019 om 14:53 schreef s8evq : > On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson > wrote: > > Tagging of regular cycle route relations is route=lcn for local routes, > rcn > > for regional routes, ncn for national routes, icn for international > routes. > > > You probably mean network=lcn instead of route=lcn > > > > I hope this clears things up? In terms of proposal, we propose one extra > > value "node_network" for the key "network_type". > > Nothing is changed, nothing is removed. So we think zero impact on the > > current base. It's up to renderers and other data users to make use of > the > > extra tag. > > So hiking node network would still be tagged with network=rwn, but you > would just add network_type=node_network. > > If yes, then I find this a bad proposal. What is the difference between > network=* and network_type=* > > Do not choose network_type because it's the most easy solution!!! > ___ > 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] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Op zo 1 sep. 2019 om 12:35 schreef Andy Townsend : > On 29/08/2019 15:52, Peter Elderson wrote: > > LS > > With the arrival of cycling node networks, the Dutch, German and > > Belgian mappers decided to claim (hijack) the network value rcn for > > those node networks. This exception was copied with the claim of > > network=rwn for the walking node networks. > > Would it be possible to try and describe in a bit more detail what has > happened, without using judgmental terms such as "hijack"? I'd start > with a link helping people understand what a "cycling node network" is. > Sure. A node network consists of numbered nodes (signs) with short routes between pairs of adjacent nodes. Eg nodes 10, 35 and 22 with routes 20-35, 10-22 and 22-35, and then each of these nodes has other connections to other nodes. The idea is that a cyclist/hiker plans a route along these nodes, so a trip consists of a series of node numbers. This differs from regular cycling/walking routes which contain chains of ways to follow, or subrelations containing the ways. Node networks were first designed and implemented for cycling in Belgium, then spread to Nederland and Germany, and they are now also used extensively for walking. Tagging of regular cycle route relations is route=lcn for local routes, rcn for regional routes, ncn for national routes, icn for international routes. Node network connections are short local routes, but if you just tag these as lcn you cannot tell the difference between regular local routes and node2node routes belonging to a node network. For rendering, checking integrity, planning and routing, the types need to be different. Same for other scopes. Rather than creating a new network value, cycle network taggers decided that rcn wasn't much used anyway, so they reserved that value for cycling node networks. The walking node networks later copied that: lwn, nwn and iwn for regular and long distance walks, rwn for walking node networks. To get an idea how that works out: this is a part of the waymarked trails hiking view in Nederland, around Eindhoven. Walking network routes are orange. https://hiking.waymarkedtrails.org/#?map=10!51.4726!5.6261 > Can you give an example of a "normal" rcn and a "node network" that > someone has tagged as an rcn and explain what the problem is with this > tagging? > The problem is that node networks are different from regular walking/cycling routes in most aspects, except the mode of transport. They need different rendering, different planning tools, different routing and different integrity checking. At the same time, node networks and regular routes for more modalities are emerging. Node networks can also have different geographical scopes. If you call them all regional, you lose the actual scope. The idea now is to stop reserving rXn (a scope value) for a specific network configuration type. rcn should just mean regional cycling, and by default regular route configuration (chain of ways) is assumed. We now want to add a separate tag for network configuration type. Could have more than one value, but for now we need only one, indicating that the route relation belongs to a node network. This will return the network=rXn in Germany, Belgium and Nederland for its intended use as documented on the OSM hiking/cycling wiki's, while at the same time opening up a more generic way to document network configuration type for data users including rendering. There are significant advantages in maintenance load as well, but that's a bonus. I hope this clears things up? In terms of proposal, we propose one extra value "node_network" for the key "network_type". Nothing is changed, nothing is removed. So we think zero impact on the current base. It's up to renderers and other data users to make use of the extra tag. Best Regards, > > Andy > > > > > ___ > 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 - Dehesa
It appears to be a specific type of farmland, so landuse=farmland + farmland=dehesa would say it all and disrupt nothing. Mvg Peter Elderson > Op 31 aug. 2019 om 12:25 heeft Diego Cruz het volgende > geschreven: > > Hi Cristoph, > > Thank you for your feedback, it's really appreciated. You are completely > right when you say that dehesa might exclude similar environments in other > parts of the world, and that is of course not my intention. I just used the > word dehesa because it appears as such in Wikipedia. Among your three > proposals, I would go with landuse=agroforestry, because it would be a way of > reflecting this mixed usage of land without being too local. As for > establishing two different landuse tags for the same territory, it could be > fine for me, but I don't know if that would create rendering problems (as I > mentioned, I'm new to this). I don't think this should be resolved with > secondary tags, because a dehesa is an entity in itself and the uses of the > land are not subordinated to each other. > > I will wait for more replies before modifying my proposal. > > Best regards > Diego > >> El vie., 30 ago. 2019 a las 12:00, Christoph Hormann () >> escribió: >> On Friday 30 August 2019, Diego Cruz wrote: >> > >> > I have recently proposed a new tag in the Wiki, because none of the >> > existing landuse tags seem to match it. A dehesa is a type of land >> > that combines a forest with either fields or pasturelands (or both) >> > at the same time. It is extensively used in the Iberian Peninsula, >> > both in Spain and Portugal. Please see the details in my proposal >> > below: >> > >> > https://wiki.openstreetmap.org/wiki/Proposed_features/Dehesa >> >> This is certainly a valid idea for inventing a new tag and it is good >> that you open up discussion early. Let me take this as an example for >> two things that have in the past been decisive on the broader success >> of tags: >> >> * local verifiability. The primary definition of your tag is for areas >> in a certain region that are in the cultural tradition of that region >> called a certain way. You try to list a few verifiable criteria what >> not to use the tag for - but these are one sided criteria. Because >> natural=wood does not rule out use as pasture (and neither does >> landuse=orchard, which is also used for cork oak plantations), >> landuse=farmland does not rule out the presence of trees or the use as >> pasture and many savannas (for which we have no specific tag at the >> moment) are created by human influence. A good tag is one where a >> local observer, even a casual one like a traveler quickly coming >> through, can without much difficulty determine locally if the tag >> applies or not. >> >> * generic meaning. As already mentioned you draft this as a region >> specific tag although agroforestry is a practice that exists in many >> different parts of the world in different forms. Such tag will either >> stay a local speciality tag without much chance for being interpreted >> by global data users and possibly mirrored by other region specific >> tags with similar but slightly different meaning or it will morph into >> a broad umbrella tag - for example for any kind of 'area with trees >> that does not really qualify as wood/forest'. Well known examples for >> such tags are natural=fell and landuse=village_green. >> >> There are three potential tagging concepts i could imagine could be >> derived from your idea that would seem more promising in that regard: >> >> * a tag for agroforestry landuse. This of course would only be locally >> verifiable if there is active agricultural use. That would only >> qualify those dehesas that are actively used for agriculture as such. >> And it would say very little about the physical appearance and >> ecological characteristics of an area. >> >> * establishing a generic tagging concept for secondary characteristics >> of areas - like use of orchards as pasture, underbrush in a forest or >> scattered trees on a meadow. This could be quite easily implemented >> using natural:secondary=*, landuse:secondary=* etc. Dehesas would >> under such scheme be something like >> >> - landuse=farmland + landuse:secondary=orchard >> - landuse=meadow + landuse:secondary=orchard >> - landuse=orchard + landuse:secondary=meadow >> >> * creating one or more region specific secondary tags for exising >> primary tags like landuse=farmland or
Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
Osm forums https://forum.openstreetmap.org/viewtopic.php?id=67218 (german forum) https://forum.openstreetmap.org/viewtopic.php?id=67219 (Belgian forum) https://forum.openstreetmap.org/viewtopic.php?id=66243 (Dutch forum) The main discussion of alternatives was on the Dutch forum. Here I present the bottom line. Vr gr Peter Elderson Op do 29 aug. 2019 om 18:56 schreef s8evq : > > On Thu, 29 Aug 2019 16:52:47 +0200, Peter Elderson > wrote: > > > We are currently discussing in the three communities how to coreect this > > exception and return rcn and rwn to their intended use. > > Where does this discussion you're talking about take place? > ___ > 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] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn
LS With the arrival of cycling node networks, the Dutch, German and Belgian mappers decided to claim (hijack) the network value rcn for those node networks. This exception was copied with the claim of network=rwn for the walking node networks. We are currently discussing in the three communities how to coreect this exception and return rcn and rwn to their intended use. To do that, we need another way to identify (members of) a route network as (members of) a node network. The network values identify transport mode and scope of routes, and these "dimensions" also apply to node networks. We do not want to add another dimension (configuration type) to the network=* values of routes. Instead, we are thnking about just adding a tag to identify segment routes as parts of a node network. The nodes themselves do not need this, since they ARE nodes and have a xxn_ref tag. In short, we are thinking to simply add the tag network_type=node_network (or network:type=node_network) to the node2node network routes. Nothing else has to change, which also means that renderers and data users who don't change anything, will not notice anything! But if they want they can make use of the separation and handle node networks different than non-node networks. Notice that no new key or value is proposed here. If new network config types arise, a new value for network_type can accommodate that.The method is applicable for all transport modes and geographical scopes. Thoughts, anyone? What did we forget? Shoot! Fr gr Peter Elderson ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)
Pig ark: https://www.youtube.com/watch?v=Rb4wTc79jY8 Nederland has "varkensflats" ie multi-storey "appartment buildings" for pigs. Wouldn't know a proper term for that in English though. I've seen it translated as "pig tower", but that term googles to https://images.app.goo.gl/WMeG3kychr7kokw7A We use "stal" (~stable) for various, but not all farm animals. I think they need to have an average of 4 limbs reaching from the body to the ground, in order to live in a 'stal'. Fish and poultry are excluded. To compensate, teenagers are granted the right to live in a "stal" as long as their brain is rewiring for adulthood. Fr gr Peter Elderson Op wo 28 aug. 2019 om 13:29 schreef Paul Allen : > On Wed, 28 Aug 2019 at 08:29, Martin Koppenhoefer > wrote: > >> >> > On 27. Aug 2019, at 23:00, Paul Allen wrote: >> > >> > Oh, and you say that a sty is for pigs (correct) and a sty is for cows >> (incorrect) >> >> probably just a copy +paste problem, and should have been cowshed >> > > Yeah, that was my thought, too. But given the nature of the rest of it, I > wasn't certain. > > This appears to be a typical language issue: in German there is one word >> (de:Stall) which is used for the “house” of many animals, e.g. cows, pigs, >> horses and chicken. To a German it seems complicated having completely >> different words for it, > > > Ah. That would explain the thinking behind it. But not the lack of > thought given to the > infeasibility of hijacking a tag used several thousand times. > > >> but as we use English tags, where stable is dedicated for horses, it >> would be misleading and unnatural for the rest of the mappers to use it for >> cowsheds or pigsties. I am also opposing this proposal. >> > > Technically, in English, a stable is for any kind of livestock. But in > common usage it has long > meant a place for horses. I doubt you'd find many British English > speakers who would think > of a stable as anything other than for horses. Ask them what's kept in a > stable and the > answer won't be "animals" it will be "horses." > > If he were to propose some other value (I can't think of one) for a > generic livestock-holding > building then I would have less reason to object to the proposal. But I > probably would still > object - we have 24,000 stables and 9,900 cowsheds. Pigs don't get many > mentions, and > we have a strange mix of names for buildings for them (what's a > pig_ark?). There are > over 1,300 chicken_coops. It would be a lot of pain to switch with very > little gain that I > can see. Maybe he could make a persuasive argument for it. > > -- > 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] Garmin waypoints and routes (was: "Roles of route members" and before that "Merging tagging scheme on wiki pages of Hiking")
Then again, OsmAnd does have a snap-to-road switch. When this is on, looking at the map when routing along a gpx-track does show the turns as arrows on the roads. When the track does not follow any accessible road (according to the OSM map), the arrows show a way around. It shows this for the whole gpx-track in advance. If you stray from the track, the arrows guide you back to the track, and the voice directions do the same. Also, the remaining distance and time to reach destination are recalculated. So I think it actually does perform routing. Still, it needs a linear sorted gpx-track, and I intend to provide those. I'm not waiting for each and every app, program, device and site to implement their own supersmart algorithms to produce a linear route from a possibly chaotic and incosistent nested route relation. If standard extraction software becomes available to do this, I will be very, very happy. I am also more than willing to help develop such software (specs, design, testing, applying), and I am sorry I can't program it myself! (as a first step, a plugin for JOSM woud be safe and relatively easy I think? May it could take a route relation containing start- and end nodes, then perform the ingenious trick with routing where members of the relation get very high weight, then write the result back (to JOSM, not OSM). Advanced sorting! Fr gr Peter Elderson Op wo 21 aug. 2019 om 20:46 schreef Peter Elderson : > I have to correct myself: I thought OsmAnd really performed routing when > navigating using a gpx trail. It doesn't, I tested it today. It translates > turns in the track into screen messgaes and spoken text messages, without > doing anything with the map. So it will send you into a ravine if your > track goes there. > But it can route you to the start of your track, and when you go > off-track, it routes you back on track. > > All the more reason why the gpx should be a correctly ordered single chain. > > Fr gr Peter Elderson > > > Op di 20 aug. 2019 om 16:57 schreef Peter Elderson : > >> Andy Townsend : >> >> On 19/08/2019 19:04, Peter Elderson wrote: >> >> >> Ok, I accept I just don't know how it's done. So how is that done? How do >> I tell my Garmin to guide me along, say, the Limes trail through the >> Netherlands? >> >> Essentially, you'd just look at the screen and follow that! I tend to >> use waypoints for an idea of things like "how long will it be until I get >> to where I'm going to stop for lunch", not for "turn left here because >> route XYZ turns left here", because you can see on the screen that route >> XYZ "turns left here". >> >> >> So it’s not done. The osm route is not used to route. You can see it and >> keep yor dot on the line, but the navigating device does not navigate along >> the route. It can navigate, it has the route, but it does not do it unless >> I create gpx from the route, send that to the device, which then recreates >> the route from the gpx. >> >> If you want to add a series of waypoints and route along those then you >> can, but want you can't typically do with one of the hiking-oriented >> Garmins is follow a particular feature. You could create an OSM-based >> Garmin map that forced a device to route along a trail at the expense of >> any other paths, but I certainly wouldn't want to do that as it would stop >> me from leaving the trail to eat in a nearby town. >> >> >> Nothing stops you from leaving the route, and I expect the device to >> route me back to the track afterwards. And it does, and so does OsmAnd. >> >> Creating a Garmin route from a GPX file is possible, but probably >> impractical, as you'd need to restrict the number of points. Apparently my >> GPSMap 64 supports 200 routes with 250 points per route, and up to 5000 >> waypoints in total. >> >> If only there were a way to store permanent routes in, say, a mapping >> database, which could be used to determine what ways to follow... >> >> You only need to load the section(s) for the next day or a few days. >> Afterwards, just remove them. No problem. I have had no problems to load >> the via degli dei as 7 sections, each a day’s walk. No restrictions >> necessary. >> >> I also loaded these in OsmAnd and had it guide me all the way >> voice-in-ear, ie not having to look at the screen at all. >> >> Where Garmin on-device routing is really useful is for when you need to >> get to somewhere but don't have an on-screen route to follow - for example >> if the weather's turned and you need to abort a previously planned route >> and get another route to your dest
Re: [Tagging] landcover dune or land form dune
I think yes, add natural=dune to map features. I think natural means that the feature has a natural way of growing or forming, even if it’s guided, maintained or engineered by man. I know some artificial dunes, many artificial woods, many artificial landscapes and beaches. After creation, they behave naturally, as they are intended to do. Plants grow, trees grow and multiply, animals settle in, sand blows and gathers, water rises, flows and lowers, just as when the feature was indeed natural. Key natural is fine there. Fr gr Peter Elderson > Op 26 aug. 2019 om 06:21 heeft Joseph Eisenberg > het volgende geschreven: > > Another question: the tag natural=dune has been included on the list > of features at Template:Generic:Map_Features:natural (used on > Key:natural) for a long time, but not on the list > Template:Map_Features:natural (used on the main Map Features page). > > Should natural=dune be added to Map Features, or does it need further > discussion? > >> On 8/26/19, Joseph Eisenberg wrote: >> Agreed. I already mentioned this to the user who created the tag on >> the page Talk:Tag:landcover=dunes >> https://wiki.openstreetmap.org/wiki/Talk:Tag:landcover%3Ddunes (note >> plural "dunes"); t >> >> There seems to be confusion about what the key "landcover" means, >> because recently there have also been pages created for >> landcover=water and landcover=hedge as well. >> >> This also brings up the question: is it appropriate to edit pages like >> this to mention the more common tags at the top, e.g. natural=dune, >> natural=sand? Often other editors are unhappy when I add something >> like "Consider using the more common tags natural=dune or >> natural=sand" - but if anyone can create a Tag: or Key: page, it seems >> important that similar and synonymous tags are mentioned at the top. >> >>> On 8/26/19, Warin <61sundow...@gmail.com> wrote: >>> Hi >>> >>> >>> There is a wiki entry for 'landcover=dune'. >>> >>> https://wiki.openstreetmap.org/wiki/Proposed_features/landcover#Landcover_tags_and_related_tags >>> >>> >>> It has 0 uses in the data base. >>> >>> >>> There is an existing tag 'natural=dune'. >>> >>> >>> https://wiki.openstreetmap.org/wiki/Tag:natural%3Ddune >>> >>> >>> >>> To me dune is a land form. >>> >>> From the Oxford Dictionary "A mound or ridge of sand or other loose >>> sediment formed by the wind, especially on the sea coast or in a desert." >>> >>> >>> So it is a mound or ridge ...ie a land form like a hill or a valley. >>> >>> >>> >> > > ___ > 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] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?
Joseph Eisenberg : > > While some have suggested that uses of the landuse=* key like > landuse=grass, landuse=village_green and landuse=recreation_area lead > to misuse of the landuse=* key, the landcover=* key appears to be even > more problematic. The problem is one particular user. The concept of landcover is very clear. Landuse, not so much. > A newer user, Henke54, has continued to create new pages like > Tag:landcover=dunes - > https://wiki.openstreetmap.org/wiki/Tag:landcover%3Ddunes (instead of > Tag:natural=dune), Tag:landcover=water (instead of natural=water), > Tag:landcover=hedge (instead of barrier=hedge) and > Tag:landcover=greenery (meant for all types of vegetation? Or > shrubberies? Flower beds?) in the Tag: space. > > I think this shows that the concept of "landcover" is not clear even > among users who promote this key over the established keys for > vegetation and landform features (eg natural=*). It shows this particular user has a problem. I would not say he is ‘among users who promote this key, he’s one user who abuses this and other keys and does not like to be corrected. > What should we do with a page like Tag:landcover=dunes? I already > tried adding a mention that natural=dune was more common and mentioned > on the Talk page that "dune" is a landform, not a landcover, but this > was reverted. There you have it. > On 8/16/19, Joseph Eisenberg wrote: >>> " it would probably be a lot of work to do this practically" >> >> That's never stopped me before! :-) >> >>> Take all tagging documentation from the wiki no matter where it is and >>> remove everything that is not strictly documenting the de facto meaning of >>> tags in the OSM database the result >> would be a pretty compact body of documentation. >> >> Are you suggesting making Tag: or Key: pages for all of the proposed >> tags/keys which are being used? That sounds like a lot of work. >> >> Wouldn't it be easier to mark crazy/theoretical/bad/abandoned >> proposals as "abandoned" and archive them, and then make it easier to >> search the wiki, including all the proposed features, rather than >> moving them all to a different wiki namespace? >> >> Or perhaps you are suggesting going through the current Tag: and Key: >> pages and removing all of the non-factual information, including some >> pages which are opinion or recommendations. >> >> While this would make a few of the pages shorter, it wouldn't >> significantly reduce the number of pages or the number of tags and >> keys documented in the wiki. Just the Map Features page alone, which >> is only a small subset of the documented tags and keys, is quite >> lengthy at the moment, and it's just descriptions of each approved or >> de facto tag (plus a few others that are in use) >> >>> On 8/16/19, Christoph Hormann wrote: >>> >>> The problem about proposal pages is that they can be infinitely >>> theoretical, non-verifiable or outright insane. So telling a mapper >>> who is thinking about inventing a new tag to search the proposals if >>> there is one that already covers what they want to do is not >>> practicable. Because even if there is a proposal that deals with the >>> same kind of situation the mapper is confronted with that does not mean >>> the proposal contains a practicable idea of how to tag this. >>> >>> The advisable approach to making tag documentation on the wiki better >>> usable is IMO not to further blur the line between documentation of the >>> de facto meaning of tags by humans and all the other uses of the wiki >>> (like proposals, automatically assembled data etc.) but more strictly >>> separating them. If you (theoretically - it would probably be a lot of >>> work to do this practically) take all tagging documentation from the >>> wiki no matter where it is and remove everything that is not strictly >>> documenting the de facto meaning of tags in the OSM database the result >>> would be a pretty compact body of documentation. >>> >>> -- >>> Christoph Hormann >>> http://www.imagico.de/ >>> >>> ___ >>> 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] Multiple tags for one purpose
Valor Naram het volgende geschreven: > > We need a system to prevent or instinct the usage of two or more tags for one > purpose. I suggest the following behaviour: > 1. Negotiating which key can be considered as official. Who will negotiate, what do they have to negiate with? What office makes it official? What process? Chances are you will never get consensus. > ___ > 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] Garmin waypoints and routes (was: "Roles of route members" and before that "Merging tagging scheme on wiki pages of Hiking")
I'll say it again: at the moment, regular people can not get a decent gpx track of a trail out of osm unless it is pre-ordered. Single chain, sorted, no branches, hooks or major gaps. These gpx-s are needed for navigating apps and devices, so you can have them guide you exactly along the trail. Nederland has numerous fixed foot trails and an ever increasing crowd walks these trails. They are adopting the digital version of a trail guide very rapidly, comparable to the way car navigation conquered the world. Please have a look at Nederland on the hiking map of waymarkedtrails to get an impression of the density of the walking trail system in the Netherlands. Fr gr Peter Elderson Op wo 21 aug. 2019 om 23:34 schreef Volker Schmidt : > > > On Wed, 21 Aug 2019 at 20:48, Peter Elderson wrote: > >> I have to correct myself: I thought OsmAnd really performed routing when >> navigating using a gpx trail. It doesn't, I tested it today. It translates >> turns in the track into screen messgaes and spoken text messages, without >> doing anything with the map. So it will send you into a ravine if your >> track goes there. >> > I knew that. Already the original Garmin etrex of before 2010 was able to > do soemthing similar (no voice, but visible signal of approach to a bend n > the track) > >> But it can route you to the start of your track, and when you go >> off-track, it routes you back on track. >> >> All the more reason why the gpx should be a correctly ordered single >> chain. >> > This is a Non sequitur, as I have tried to explain before. > Volker > > > ___ > 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] Garmin waypoints and routes (was: "Roles of route members" and before that "Merging tagging scheme on wiki pages of Hiking")
I have to correct myself: I thought OsmAnd really performed routing when navigating using a gpx trail. It doesn't, I tested it today. It translates turns in the track into screen messgaes and spoken text messages, without doing anything with the map. So it will send you into a ravine if your track goes there. But it can route you to the start of your track, and when you go off-track, it routes you back on track. All the more reason why the gpx should be a correctly ordered single chain. Fr gr Peter Elderson Op di 20 aug. 2019 om 16:57 schreef Peter Elderson : > Andy Townsend : > > On 19/08/2019 19:04, Peter Elderson wrote: > > > Ok, I accept I just don't know how it's done. So how is that done? How do > I tell my Garmin to guide me along, say, the Limes trail through the > Netherlands? > > Essentially, you'd just look at the screen and follow that! I tend to use > waypoints for an idea of things like "how long will it be until I get to > where I'm going to stop for lunch", not for "turn left here because route > XYZ turns left here", because you can see on the screen that route XYZ > "turns left here". > > > So it’s not done. The osm route is not used to route. You can see it and > keep yor dot on the line, but the navigating device does not navigate along > the route. It can navigate, it has the route, but it does not do it unless > I create gpx from the route, send that to the device, which then recreates > the route from the gpx. > > If you want to add a series of waypoints and route along those then you > can, but want you can't typically do with one of the hiking-oriented > Garmins is follow a particular feature. You could create an OSM-based > Garmin map that forced a device to route along a trail at the expense of > any other paths, but I certainly wouldn't want to do that as it would stop > me from leaving the trail to eat in a nearby town. > > > Nothing stops you from leaving the route, and I expect the device to route > me back to the track afterwards. And it does, and so does OsmAnd. > > Creating a Garmin route from a GPX file is possible, but probably > impractical, as you'd need to restrict the number of points. Apparently my > GPSMap 64 supports 200 routes with 250 points per route, and up to 5000 > waypoints in total. > > If only there were a way to store permanent routes in, say, a mapping > database, which could be used to determine what ways to follow... > > You only need to load the section(s) for the next day or a few days. > Afterwards, just remove them. No problem. I have had no problems to load > the via degli dei as 7 sections, each a day’s walk. No restrictions > necessary. > > I also loaded these in OsmAnd and had it guide me all the way > voice-in-ear, ie not having to look at the screen at all. > > Where Garmin on-device routing is really useful is for when you need to > get to somewhere but don't have an on-screen route to follow - for example > if the weather's turned and you need to abort a previously planned route > and get another route to your destination from where you currently are. > It's also useful where there are natural obstacles like rivers, where the > distance on foot may be significantly more than the as-the-crow-flies > distance. > > Best Regards, > > Andy > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
