Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

2020-12-24 Thread Peter Elderson
Option 1
addr:range=* specifies the increment

addr:range=even
addr:housenumber=2..250

if .. is used, a hyphen combined with a range can be handled.

addr:range=odd
addr:housenumber=200-01..200-91

In these examples, a default of 2 would simplify things: .. infers a range,
increment is default 2 and - is never a range indicator.

Error to be expected: people just copying the housenumber plate may use
2-250.
When using the explicit addr:range tag, the format error may be detected
because .. is missing.

Peter Elderson


Op do 24 dec. 2020 om 15:12 schreef Paul Allen :

> On Thu, 24 Dec 2020 at 10:14, Martin Koppenhoefer 
> wrote:
>
>> maybe we should add an expression marker, like {10..20} to make it more
>> explicit and avoid confusion with typos?
>>
>
> In programming, you also have the ability to define the increment,
> which defaults to 1 if left unspecified.  That way you can distinguish
> between 10, 11, 12, 13, 14, 15, 16 and 10, 12, 14, 16 (or even
> 10, 13, 16).  You could argue that for addresses the increment
> ought to default to 2, since that is most commonly encountered.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

2020-12-20 Thread Peter Elderson
I'd say they are small mounds.

Hillock sounds too, er, hilly.

Peter Elderson


Op zo 20 dec. 2020 om 11:39 schreef ael via Tagging <
tagging@openstreetmap.org>:

> > I'm uncomfortable with hillock/hillocky as a value.
>
> "Hillock" is quite common in British English, not that I am comfortable
> using it as a tag.
>
> ael
>
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Peter Elderson
I'll tag both ways then, or better map none at all? Shirt, another dilemma.
I need something stronger than tea.

Peter Elderson


Op wo 16 dec. 2020 om 17:04 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> Dec 16, 2020, 16:49 by tomasstrau...@gmail.com:
>
> 2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
>
> I agree that it is useful only for primitive rendering of water areas
> (that possibly filters water areas by area but does not distinguish
> between lakes and rivers). It may be worth mentioning.
>
> But it is also the most typical and common way of rendering things.
>
>
> How do you decide that it is most typical and common way of rendering
> things?
> ALL maps I created or seen in GIS/Cartography world, be it online or
> printed, interpret water classes differently, especially
> basins/riverbanks...
>
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
>
> https://www.openstreetmap.org/#map=14/54.3643/18.7150
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=H
> <https://www.openstreetmap.org/#map=14/54.3666/18.7138=T>
>
> In contrast
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=O
> <https://www.openstreetmap.org/#map=14/54.3666/18.7138=T>
> appears to distinguish seas/oceans
>
> Best system is to use codes, not names for keys/values, but that is a
> totally different "saga".
>
> Feel free to propose this one.
> ___
> 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 put a name tag on an area with more than one type?

2020-12-15 Thread Peter Elderson
stevea :

> (Personally, I find JOSM’s relation editor to be one of its most elegant
> features for a data structure as relatively complex as a relation.
>

I am not qualified to judge elegance, but I find JOSM's relation editor the
best there is. I don't think relations are very complex data structures,
but the construct is versatile. It's what people do with them that makes it
complex. But hey, the same goes for the node, the way and the area.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - crossing=priority

2020-12-13 Thread Peter Elderson
Colin Smale  het volgende geschreven:
> 
> 
>> 
>> On 2020-12-13 21:53, Peter Elderson wrote:
>> 
>> Just to clarify:
>>  
>> > crossing=priority Indicates that the node is a pedestrian crossing  
>> when applied to highway=cycleway, should this read bicycle crossing?  
>>  
>> when applied to a highway=cycleway, does the tag imply priority for 
>> cyclists, pedestrians, or both?
>>  
> And what happens if a cycleway crosses a footway, as happens commonly here in 
> the Netherlands?
>  
> We also have an analogous problem here where cycle tracks cross roads. In 
> many (but nowhere near all) cases the cycleway has priority

To be clear, traffic from the right has priority, unless signing indicates 
otherwise. Pedestrians have to give way, unless zebra marking indicate they 
have right of way. Dismounted cyclists count as pedestrians. Flashing bulbs 
have been banished a long time ago, in favor of (fluorescent or backlighted) 
"zebra ahead" warning signs.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - crossing=priority

2020-12-13 Thread Peter Elderson
Just to clarify:

> crossing=priority Indicates that the node is a pedestrian crossing  
when applied to highway=cycleway, should this read bicycle crossing?

when applied to a highway=cycleway, does the tag imply priority for
cyclists, pedestrians, or both?

> belisha_beacon=yes|no
Is belisha beacon a generally known term outside the UK?
Since only presence is significant,  the value no is useless

> segregated=boolean (yes/no) (no default assumed)

Since the proposal talks about pedestrians, cycleways and horses crossing:
what exactly is segregated when segregated=yes is applied to a cycleway?
And with segregated=no, do motorists get a warning that horses may cross on
the cycleway?


Peter Elderson


Op zo 13 dec. 2020 om 21:08 schreef ipswichmapper--- via Tagging <
tagging@openstreetmap.org>:

> Yes, most likely this won't be required. However I have kept it there in
> case it works differently in other countries. Maybe not all zebra crossings
> in Singapore have belisha beacons (for example, I don't know if this is
> true). That is why I am leaving it open for discussion for now, if after
> the RFC it is decided that this is a bad idea I'll remove it.
>
> Thanks,
> IpswichMapper
>
> --
>
>
> 13 Dec 2020, 19:50 by tagging@openstreetmap.org:
>
> It seems to be proposing also belisha_beacon=yes that
> is now unused
> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>
> At the same time it has
> "However, in countries like the UK, where belisha beacons are used, every
> single zebra crossing has belisha beacons installed, so there is no need
> to tag them"
>
> There is also
> "Indicates the presence of a "belisha beacon" at the crossing. (Most
> likely unnecessary, discuss below)"
>
> Given there is no indication that it would be useful or needed I think
> that it should be not proposed.
>
> If that it would be useful or needed it can be proposed separately.
>
> Note that having two proposals in one will result in people voting against
> if there are against any of them, so splitting would be a good idea
> anyway.
>
> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
> <https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority#Tagging>
>
> Here is my first proposal for a tag to describe pedestrian crossings where
> the pedestrian has right of way over all vehicles on the road from the
> moment they have indicated their intent to cross. I created this because
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the
> proposal for more details.
>
> Thanks,
> IpswichMapper
>
>
>
> ___
> 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 put a name tag on an area with more than one type?

2020-12-13 Thread Peter Elderson
My answer only targets the question in the subject.

No matter whether you put the same name on all parts, or on or some kind of
collective, you need a way for data users to know that all the parts
together have a name.
Tagging the same name on all parts makes the name a free text id
needing uniqueness - for me a bad choice.
Yet another polygon around the area, don't like that. I think we have too
many of those already.
Tagging all parts with a truly unique Id in a special key could do the
trick, but who issues/manages the unique ids?
Putting the parts as members in a relation achieves the same: a unique Id
common to all the parts; the name tag and possible other common attributes
go on the relation.
This gives renderers the exact extent of the total area, and the extents of
the subareas, which can have names and other attributes of their own.
Since an MP does not cover all possible layouts, you would need a different
type of relation. Maybe an existing type can be used, or a specialised type
can be defined.

I would think a pilot project could test the concept for mappers, renderers
and other data users. If succesful, showcase. If not, document and delete.

Peter Elderson


Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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 put a name tag on an area with more than one type?

2020-12-11 Thread Peter Elderson
Actually, there is no Rijn in Rotterdam. But that does not change the argument.

Mvg Peter Elderson

> Op 11 dec. 2020 om 18:11 heeft Christoph Hormann  het 
> volgende geschreven:
> 
> 
> 
>> Anders Torger  hat am 11.12.2020 17:07 geschrieben:
>> 
>> The least bad way I've come up with is to just name all polygons 
>> belonging to the same wetlands the same,
> 
> That is widely considered to be the correct way.  It is established practice 
> that mapping things like forest, wetland, farmland etc. can be split to 
> differentiate tagging (like leaf_type, wetland type, crop etc.).  The name 
> tag is then applied to all components.  Same as for waterways or roads where 
> you can also split and apply the name to the components.
> 
> This also matches the general concept in OSM that names are typically local 
> properties and only locally verifiable.  The Rhine river is called Rhein in 
> Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.
> 
> -- 
> 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


Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

2020-11-26 Thread Peter Elderson
Mass testing without the strict isolation doesn't work, no matter how
important the sport or the person. Strict isolation (not 'bubbles') without
mass testing will work.
Anyway, It's almost done, then all temp structures and facilities will
disappear in favour of soon forgotten "quick response" plans.

Peter Elderson


Op do 26 nov. 2020 om 21:07 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Am Do., 26. Nov. 2020 um 18:35 Uhr schrieb Peter Elderson <
> pelder...@gmail.com>:
>
>> Well, mass testing did not stop the virus anywhere, it just costs a lot,
>> drives people to despair and boosts the numbers.
>>
>
>
> this is off topic here, but apparently the Chinese have succeeded in
> stopping the pandemic there, by strict isolation and mass testing whenever
> a new case was discovered somewhere.
>
> 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] RFC: vaccination / COVID-19 vaccination centres

2020-11-26 Thread Peter Elderson
Well, mass testing did not stop the virus anywhere, it just costs a lot,
drives people to despair and boosts the numbers. Anyway, as soon as
vaccination becomes common practice, COVID-19 is just another virus
disease  you can get vaccinated against in a regular way, same as others.
All the special facilities will disappear. OSM-forums will carry on the
debate whether they should be tagged as historic or abandoned until the
next pandemic.

Peter Elderson


Op do 26 nov. 2020 om 15:59 schreef Paul Allen :

> On Thu, 26 Nov 2020 at 02:35, stevea  wrote:
>
>> I'm in California, where it's almost cliché we love our cars and car
>> culture, but it is true that not only here but in many USA states, we have
>> "drive-thru" COVID-19 testing centers.
>
>
> In the UK we don't have much of a drive-thru anything except maybe some
> fast-food outlets of American origin.  Yet all the covid-19 testing
> centres I'm
> aware of are strictly drive-thru.  As in you're not allowed to turn up on
> foot,
> because if you're infected you may pass it on to other pedestrians you walk
> near.  And they're drive-thru because the swabs are taken in the open.
> The swabs are taken in the open because there is far less risk of
> transmission outdoors than indoors.
>
>
>>   I would guess that vaccination centers that are also "drive-thru" are
>> likely soon (early 2021?), too.
>
>
> The same reasons that make the test centres drive-thru apply to
> vaccination centres.  Eventually, when we have herd immunity
> (one way or another) indoor vaccination may be feasible (but
> probably undesirable).  The health workers will be vaccinated
> first so they won't be at risk either way, but these places will
> be handling large numbers of people and having them all wait
> indoors is a good way of infecting lots of people.
>
>
>>   These being mapped with "indefinite duration" seems a bit much (sorry,
>> Brian), but they are usually more of a "pop-up" kind of thing:  one-time or
>> "only on Saturdays" or something like that.
>
>
> There is a temporary, short-duration, won't be there for long, test centre
> just
> popped up in my town because a couple of weeks ago some idiots decided
> to celebrate the end of firebreak restrictions by going to the pubs and
> ignoring social distancing completely.  Fifty-five cases came of that, and
> three hundred contacts have been traced.  I expect it to go away in a few
> weeks if the outbreak gets under control.  I'm not confident the outbreak
> will be under control very soon because a lot of the celebrants were
> shop workers.
>
> But as well as that pop-up test centre because of the sudden surge, there
> is an existing test centre.  That's based at the leisure centre that was
> converted to an emergency overflow hospital several months ago. I only
> found out the test centre was there a few days ago because we try to
> keep their locations secret, so I probably won't map it.
>
> Vaccination centres are going to handle more people than test centres
> do because nearly the entire population will have to be vaccinated but
> only a very small fraction of the population is tested (we ought to be
> testing everyone at least once a week, but my country's government
> is somewhat incompetent).
>
> --
> 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] RFC: vaccination / COVID-19 vaccination centres

2020-11-25 Thread Peter Elderson
We (Nederland) will likely use the flu vac system of local practitioners
and old people's homes to do groups at risk first, and health care
personnel will take care of themselves while administering.Will take two to
three weeks for the first shot, and if a second shot is needed, 6 weeks.

The rest will probably need to apply, and I think the Covid testing
facilities will be used for the mass vax. This will probably take months,
mainly because of supply chain and cold chain problems. Everybody will
turn into an opportunist, politicians will literally lose their voices
because of all the yelling at each other. Then it will become a standard
yearly vaccination and we will all return to normal. O, the stories we will
tell our grandchildren when they really just want to hang out with each
other and play games...

Best, Peter Elderson


Op wo 25 nov. 2020 om 22:33 schreef Paul Allen :

> On Wed, 25 Nov 2020 at 20:01, Philip Barnes  wrote:
>
> Although in this case I would expect the approach to be to set up sessions
>> for schools, universities and at larger employers and for the general
>> population it will simply attend an appointment at their local medical
>> centre.
>>
>
> Even back in the Before Times, flu jabs were not given at the local medical
> centre but in a large exercise hall.  I think that was more to do with
> numbers
> than anything else.  Covid is more infectious than flu (but less so than
> measles)
> and the indications are strong that you're at a lot greater risk indoors
> than
> outdoors.
>
> I doubt that testing or vaccination will take place at local medical
> centres.  All
> the testing centres I know of, whether short-term or longer-term have the
> testing conducted outdoors.
>
> Right now, because of a recent surge in cases in my town the medical
> centre is only permitting people to turn up if they get an appointment
> because it is "absolutely necessary" (their words, not mine) they see
> a doctor.
>
> I've been paying a lot of attention to this stuff (because of underlying
> health conditions which mean I'm very unlikely to survive it) and I
> seriously doubt we'll see testing or vaccination conducted indoors
> until all medical staff have been vaccinated and enough of the
> general population have been vaccinated to achieve herd
> immunity.
>
> --
> 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] Tagging Cycle Route Relations vs. Ways

2020-11-18 Thread Peter Elderson
I see changeset source tags as the source(s) used for the work, not
necessarily the source of every change in the changeset.
Most of the source tags I see state the original source of the object, not
the latest source. The original source does not change when a tag or the
geometry is altered.

The history of objects tells me who has touched it, what has changed, but
not why and what the source was, and the associated changeset tags usually
only tell me why the object was affected, but nothing specific for the
object (unless the object happens to be the only thing changed in the
changeset).

I would rate this information: sometimes useful but not very reliable.
Technical improvements will not fix this.  What the mappers put there could
do with improvement. The challenge is how to get the mappers to do it.

Peter Elderson


Op wo 18 nov. 2020 om 19:09 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Am Mi., 18. Nov. 2020 um 13:19 Uhr schrieb ael via Tagging <
> tagging@openstreetmap.org>:
>
>> On Wed, Nov 18, 2020 at 12:09:40AM +0100, Martin Koppenhoefer wrote:
>> We have tags like source:name and source:outline for more specific
>> tagging.
>>
>
>
> yes, every tag could get a source tag. It would mean a lot of additional
> work for mappers, and the benefit would probably be very small. Usually
> when you check an object for its correspondence with reality, you either
> find the tags accurate or wrong, for various reasons they could be wrong,
> most likely is a change of the thing in the real world. A source tag will
> not help you with this. To me, the most interesting information when
> looking at an edit is whether the person has been on the ground or not.
> source=Bing does not really tell you this, because many people use it when
> they are adding information and Bing is visible in the background, but it
> does not mean that every piece of information that they add actually comes
> from Bing.
>
>
>
>
>
>>
>> > From a practical point of view, I am mostly ignoring source tags,
>> because
>> > they are almost never accurate. Typically someone has added them some
>> > versions ago and nobody in between has bothered to remove or update the
>> > tag. To know this, you will have to dive into the object history anyway.
>>
>> Then  you are part of the problem :-) It is very annoying when the
>> source tag is accurate until someone, nearly always an armchair mapper,
>> who comes along and changes things without updating the source tag.
>>
>
>
> Most source tags I see are source=Bing and when I add information from a
> survey, I either do not change it, or sometimes I remove it because it is
> not valid any more at this point.
>
>
>>
>> Let's encourage people to use the source tag properly rather than cause
>> further decay. Or come up with a better solution, which is definitely
>> not a changeset comment.
>
>
>
> the changeset "comments" are actually structured tags, and from past
> discussions it is the preferred way over source tags on individual items.
> Source tags on items are the older method, they have already proven to fail
> in real world conditions in OSM ;-)
>
> 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] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Peter Elderson
AFAIK, a relation is meant to represent an entity of its own, which can be
observed and verified in the field.
Its tags should be the tags of this entity, not the tags shared by the
members. It's not a relational database model.

If many streets are called "Polygon Alley" you tag each one with
name=Polygon Alley. No normalization applies, just tag it.
Best, Peter Elderson


Op ma 16 nov. 2020 om 18:17 schreef Seth Deegan :

> Honestly I think I'm just confused.
> I guess ways *do have* official names, it's just that I keep on thinking
> about the possible *conceptual* conflicts between two different Routes
> under one way (this statement probably doesn't make sense).
>
> Also, I'm someone who loves relations and finds myself thinking about
> putting all of the elements that share a tag under a relation constantly!
> I guess just keeping them in their original Ways is the way to go.
>
> However, *if there was a way* to indicate the "primary" relation for a
> Way, then I'd be all for it.
> IDK. Save space wherever possible seems to be the common theme.
> Problems with this though would be that renderers/data consumers would
> have to go into the relation every time they want to find more tags for an
> element.
> There are pros and cons. I'm also aware relations aren't categories.
>
> Thank you for the clarification.
>
> On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
> wrote:
>
>> Hello,
>>
>> Route relations 'group' together the nodes/ways/relations that form a
>> cycling route. The nodes/ways/relations themselves should not be tagged
>> with the name of the route, like you quoted the wiki.
>>
>> The name of a way should be the official name of the way, not the name of
>> the relation(s) that way is part of. I refer to Key:name [1] which states
>> "The names should be restricted to the name of the item in question only
>> and should not include additional information not contained in the official
>> name such as categories, types, descriptions, addresses, refs, or notes."
>>
>> So the question remains for the ways you mention that are tagged with
>> name of the cycling route. Are those ways officially named exactly as the
>> relation name? If not, I would classify this situation as 'tagging for the
>> renderer' (getting the renderer to show the name of the cycling route).
>>
>> On the subject of rendering: there are many renderers that show cycling
>> route relations [2]. Some of them [3] are even advanced enough to grasp the
>> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
>> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>>
>> Kind regards,
>> *Hidde Wieringa*
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:name
>> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
>> [3] https://cycling.waymarkedtrails.org
>> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
>> [5]
>> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>>
>>
>> On 16-11-2020 17:17, Seth Deegan wrote:
>>
>> The Cycle Routes Wiki Page
>> <https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks>
>> states:
>> "It is preferred to tag the cycle routes using relations instead of
>> tagging the ways."
>>
>> If I come across a route that has the Ways already tagged with the name
>> <https://wiki.openstreetmap.org/wiki/Key:name>=* of the route, can I
>> delete the name <https://wiki.openstreetmap.org/wiki/Key:name>=*s in the
>> Ways and just create a Route Relation with the name?
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>><https://wiki.openstreetmap.org/wiki/Key:surface>=* and source
>><https://wiki.openstreetmap.org/wiki/Key:source>=* (like the official
>>map of the route).
>>- Ways with two or more routes wouldn't be tagged name
>><https://wiki.openstreetmap.org/wiki/Key:name>=route 1 & route 2
>>
>> <https://wiki.openstreetmap.org/w/index.php?title=Tag:name%3Droute_1_%26_route_2=edit=1>
>>  and
>>instead have their respective Relations. This could help with preferred
>>routing/data usage in general.
>>
>>
>> I would propose th

Re: [Tagging] Deprecate water=pond?

2020-11-13 Thread Peter Elderson
Ah, profiling! Hadn't thought of that yet.

Best, Peter Elderson


Op vr 13 nov. 2020 om 10:18 schreef Michael Patrick :

>
> I am surprised nobody has suggested a pondness or lakicity scale yet.
>>
>
> It isn't unusual outside of OSM for relative percentages of the different
> meanings to be accounted for. For example for Great Pond (
> https://www.topoquest.com/map.php?lat=44.5=-69.8=nad83=16
> ) with a surface area of 13 square miles
>
> lake 15%
> reservoir 84%   ( volume added to the original lake by the dam )
> pond 1%
>
>
>
> <#m_2101975028351855335_m_-6680278241776399936_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Deprecate water=pond?

2020-11-12 Thread Peter Elderson
I am surprised nobody has suggested a pondness or lakicity scale yet.

Best, Peter Elderson


Op do 12 nov. 2020 om 02:46 schreef stevea :

> If we're going to do "this:"
> > So perhaps we could create a new tag water=natural_pond for small,
> natural or semi-natural lakes which are currently tagged as water=pond, and
> water=artificial_pond or water=man_made_pond for the majority of water=pond
> features which are clearly not natural, such as ponds in gardens.
>
> it seems we should ponder (sorry, couldn't resist) the myriad
> possibilities for ponds both artificial AND natural and make a formal
> proposal that "covers all cases," at least as best we can in a formal
> proposal.  This would clarify (sorry, couldn't resist) what they're all
> "used for," as in settling in the case of a wastewater treatment plant,
> decorative as in somebody's backyard garden, natural, as in "shallow,
> nature-created, not-deep-enough to be called lake..." and so on.  Don't
> forget to consider (and document) potential overlap with things like
> leisure=swimming_pool and possibly others.
>
> We might get a good start on doing this in a talk page, but I think it
> would greatly benefit from the thought that goes into a formal proposal:
> worldwide consideration of the semantic space being described, rather clear
> syntax and namespaces described, how to decide one from the other,
> linguistic differences (as Joseph mentioned there can be a flattening in
> particular languages that might deserve extra clarity), how to migrate from
> existing tagging to the proposed tagging, and all the rest that formal
> proposals treat (what wiki need to update, et cetera).
>
> I admire Joseph's "tossing here" what he wrote, as it gets things started,
> but I believe the subject is much richer than this.
>
> It would also focus efforts by those who care and in as much detail and in
> one place as such a specific topic deserves.  While I don't write this to
> discourage posts to this list (I don't, as this list is a valuable place to
> discuss), I have also noticed a trend towards formal proposals.  "Ponds"
> seems like an excellent candidate for one.
>
> SteveA
> ___
> 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] Deprecate water=pond?

2020-11-11 Thread Peter Elderson
There is no "it". Everybody has their own "it", and even that may be
inconsistent.
I am not opposed to ponds and lakes - I just don't see a common definition
coming up without "generally" (but not always), "typically"(but may be
different), "usually"(except where it's not), "in most countries" (but not
everywhere) etc etc.

I don't think most bodies of water can be tagged as pond or lake by any
common standard, in a way that all agree. Nor do I think that is a problem.

Best, Peter Elderson


Op wo 11 nov. 2020 om 19:51 schreef Brian M. Sperlongano <
zelonew...@gmail.com>:

>
>
> On Wed, Nov 11, 2020 at 12:29 PM Peter Elderson 
> wrote:
>
>
>> Everybody knows a difference,
>>
>
> If "everybody knows it", then let's define what that difference is and
> write it down.  That is why this list exists.  It is a bad idea to presume
> that different cultures and languages share a common understanding and
> terminology.  The reason we are even discussing this in the first place is
> precisely because the difference between pond and lake is not universally
> clear.
> ___
> 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] Deprecate water=pond?

2020-11-11 Thread Peter Elderson
I am getting a foot vs hiking feeling. Everybody knows a difference, nobody has 
the same difference. In the end, it does not matter.

Mvg Peter Elderson

> Op 11 nov. 2020 om 16:02 heeft Brian M. Sperlongano  
> het volgende geschreven:
> 
> 
> If the consensus is to go with a limnological definition - I think that's 
> fine.  Let's lay out the limnological description of "pond" and "lake" and 
> let mappers sort out edge cases based on their best interpretation of the 
> definitions provided.  That's no different than the wetland= tag in which 
> there are lots of edge cases in the real world that are not quite one or the 
> other.  I assume there will be cases where "such and such pond" is properly 
> tagged water=lake and vice versa, but that's fine if there's a definition to 
> stand on.
> 
> If we are going with a "what people call it" definition, then the distinction 
> is purely redundant and worse may not translate appropriately into other 
> languages which might have a different array of terms for such bodies of 
> water.
> 
>> On Wed, Nov 11, 2020 at 8:30 AM Paul Allen  wrote:
>>> On Wed, 11 Nov 2020 at 13:12, Brian M. Sperlongano  
>>> wrote:
>> 
>>> Is it actually desirable to distinguish a "lake" from a "pond"?  If so, 
>>> what is the difference?  Is it just that a body of water is named "XYZ 
>>> Pond" versus "XYZ Lake"?  If so, isn't water=pond versus water=lake derived 
>>> from and redundant with name?
>> 
>> It's possible to make the distinction.  It's not clear-cut.  There are 
>> several
>> definitions which are not entirely compatible with each other, but they
>> have more similarities than differences.  Edge cases are hard.
>> 
>> See, for example:
>> 
>> https://lakes.grace.edu/ponds-vs-lakes-whats-the-difference/
>> https://www.lakemat.com/whats-the-difference-between-a-lake-and-a-pond/
>> https://www.des.nh.gov/organization/commissioner/pip/factsheets/bb/documents/bb-49.pdf
>> https://www.lakescientist.com/lake-facts/how-lakes-differ/
>> 
>> Most of them agree that lakes have aphotic zones (deep areas that receive
>> no sunlight, preventing plants from growing there).  But wave height, 
>> uniformity
>> of temperature, and area of water may play a part.  And, of course, there's 
>> what
>> the locals call it.
>>> 
>>> Is there a conceivable scenario where a data consumer or renderer would 
>>> care about the distinction between these two tags?
>> 
>> Renderers will probably treat them identically  A limnologist would find the
>> distinction useful. 
>> 
>> There is also a distinction between pools and ponds.  However, since pools
>> are supplied by a spring or a stream, most can be distinguished by other
>> water=* occurring in conjunction with them (a lot of the ponds I've mapped
>> are actually pools).
>> 
>> https://www.askdifference.com/pool-vs-pond/
>> 
>> -- 
>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-09 Thread Peter Elderson
The problem is that natural and artificial are not neatly separated IRL. In 
Nederland, nature is neatly cut, shaven and shaped. Currently, natural style is 
preferred. "New nature" is the hype, where heavy machinery creates new 
landscapes including ponds, lakes, streams and wetlands. Sea dykes are shaped 
like dunes. Etc. So every pond is made to look natural, and every lake is 
reshaped and maintained. 

We have words for pond ("vijver") and lake ("meer") but very loosely defined, 
and many more terms for other bodies of water. 

I think a clearcut definition would not help at all in this case.

Peter Elderson

> Op 10 nov. 2020 om 06:30 heeft Joseph Eisenberg  
> het volgende geschreven:
> 
> 
> The tag water=pond was added with a large number of other types of "water=*" 
> in 2011, but it has a poorly defined description. 
> 
> "A pond: a body of standing water, man-made in most cases, that is usually 
> smaller than a lake. Salt evaporation ponds should be tagged with 
> landuse=salt_pond, open-air swimming pools — with leisure=swimming_pool."
> 
> So it might be artificial, like a landuse=reservoir or water=reservoir, but 
> smallish. Or it might be natural like a water=lake, but smallish. However, 
> nothing on the water=lake page defines a lower limit for the size of a lake.
> 
> This is a shame, because all the other values of water=* are clearly defined 
> as only natural, or only artificial, and waterway=* features are also clearly 
> divided. Furthermore, the original lags landuse=reservoir and landuse=basin 
> were also clearly artificial, while lakes were natural.
> 
> But the biggest problem is that there is no way to define a lower size for a 
> lake or reservoir, or an upper size for a pond. And the size of the area is 
> easier available from the geometry of the feature, so it doesn't need to be 
> mentioned in the tag. 
> 
> I think the best option is to deprecate water=pond and suggest using 
> water=lake for natural lakes, even small ones, and use water=reservoir or 
> water=basin (or landuse=reservoir or =basin if you prefer) for the artificial 
> ones. 
> 
> -- 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] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-05 Thread Peter Elderson
In Nederland it is a normal option to arrange a temporary mourning room 
("rouwkamer") in the house. Any room could be used. I don't think this counts 
as a mappable amenity. Most people, though, use a permanent mourning facility, 
usually with several viewing/mourning rooms because people do not die on 
schedule one at a time.

Peter Elderson

> Op 5 nov. 2020 om 19:56 heeft Joseph Eisenberg  
> het volgende geschreven:
> 
> 
> I'm not able to find any website which clearly talks about a specific 
> "mourning room", though it is certainly documented that the front room of a 
> house, often known as a "parlour" at the time, would be used to view the 
> corpse of a deceased family member. This practice is still common in 
> Southeast Asia, BTW. This room might also have been called a "sitting room", 
> and now is likely the "living room".
> 
> Do you have a link? Do you think that anyone in the 2000s is likely to be 
> confused by the term amenity=mourning_room?
> 
> -- Joseph Eisenberg
> 
>> On Thu, Nov 5, 2020 at 10:36 AM Paul Allen  wrote:
>>> On Thu, 5 Nov 2020 at 18:19, Steve Doerr  wrote:
>>>> On Thu, Nov 5, 2020 at 1:14 PM Paul Allen  wrote:
>>> 
>>>>> On Thu, 5 Nov 2020 at 08:46,  wrote:
>>>  
>>>>> amenity=mourning_room
>>>> 
>>>> Unacceptable.  "Mourning room" was the old name for what is now
>>>> known as a "living room" (and was also known as a "parlour"),  A
>>>> room in somebody's house which was pressed into use for the
>>>> display of a corpse when needed.
>>>> 
>>> 
>>> I think you'll find that's a 'morning room', defined by the OED as 'a room 
>>> used as a sitting room during the morning or early part of the day'.
>> 
>> Those existed too, if you were rich enough to have a very large house
>> and could move from room to room to follow the sun.  For most
>> people, there was only one sitting room which also served as a place
>> to put a corpse.  I thought I gave a link explaining this.
>> 
>> -- 
>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-05 Thread Peter Elderson
> rate the following "favourable", "acceptable" or "unfavourable"?
>
> amenity=mourning
>

acceptable, though I think an amenity should be a feature, not an activity


> amenity=place_of_mourning
>

favourable. Secondary tags could add details if necessary


> amenity=mourning_room
>

unfavourable. Too specific.


> amenity=viewing_arrangements
>

unfavourable. I think an amenity should describe a feature, not
arrangements.


> amenity=deceased_viewing
>

unfavourable.


> 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] religious bias - Re: Feature Proposal - Voting - (Chapel of rest)

2020-11-04 Thread Peter Elderson
place_of_mourning then? Just like place_of_worship?

One could argue that this misses the point, because it's about viewing the
deceased and you can mourn anywhere. Then again, you can worship anywhere,
but in these special places the worshipped entity is usually represented
and highlighted by objects and decorations, and often actually presumed
present. The deceased may also be just represented.


Peter Elderson


Op wo 4 nov. 2020 om 23:30 schreef Paul Allen :

> On Wed, 4 Nov 2020 at 20:50, Tom Pfeifer  wrote:
>
>> I was surprised that this tag is rushed into voting despite the arguments
>> against it even here in the tagging list discussions.
>>
>
> The proposal itself contains paragraphs indicating it is a work in progress
> rather than a finished proposal.  I would have commented but the wiki
> is using a black-hole service that has blocked a large chunk of
> addresses belonging to my mobile network because some open
> proxies were detected.  This is not really ideal for a mobile
> service where IP addresses are very volatile.
>
>>
>> Let's summarize the criticism first, and look into the alternative
>> "mourning room"
>>
>
> Not in current use in British English.  And even when it was used, it
> generally referred to the room in a house that we now call the
> "living room."  See
> https://www.vintag.es/2018/01/living-room-what-we-call-today-was.html
> Also not really suited to a large, dedicated building with more than one
> room
> for this purpose.  It's that "room" bit that is the problem.
>
> * Vollis (the proposer) 18 Sep: ""chapel" will be opposed by some for
>> being religiously connotated"
>>
>
> He was correct.  But it's rare for a proposal to get unanimous approval.
>
>>
>> * Peter Elderson 21 Sep: "I have heard mourning chapel, mourning room,
>> funeral chapel, funeral room.
>> Chapel of rest does not seem right to me"
>>
>
> As I understand it, English (British, American or any other variety) is not
> Peter's first language.
>
>>
>> * Clifford Snow 24 Sep: "Chapel of Rest" sounds to me more like a
>> marketing term not something we should be using in OSM.
>>
>
> What something "sounds like" to an individual is not a strong determinant
> of
> its propriety.
>
>>
>> * Michael Patrick 24 Sep: 'Chapel of Rest' seems to be a dated UK
>> specific term.
>
>
> It's what they're known as in my part of the UK.  So still contemporary in
> at least
> parts of the UK.
>
>
>> ... The euphemistic 'Chapel of Rest' is more generically known as
>> 'Viewing /Visitation Service',
>>
>
> "amenity=visitatation_service" makes even less semantic sense than
> "amenity=mourning_room."  It's not a term I've encountered, anyway.
>
>
>> * 27 Sep: 'Chapel of Rest' seems to be one of those terms like 'Take the
>> goat to the butcher...
>>
>
> That sentence no sense makes.
>
>
>> * 28 Sep: since OSM is an international project, my practice is to make
>> it as easy as possible for non-native English users.
>>
>
> That is why editors have translations of their presets.
>
>>
>> Indeed, the proposed value contains 'chapel' which is biased to christian
>> religion.
>
> It might be used in British English, however that is biased itself for
>> having
>>
> Christianity as a cultural background.
>>
>
> Congratulations.  You have successfully argued that we must change from
> using British English to the language of a country which has no
> religious cultural background whatsoever.  Offhand, I can't think of
> such a country but why should that stop us?
>
> "Chapel of rest" is an euphemism that avoids death-related terminology,
>> butmight be mistaken for a chapel where somebody could rest along a hiking
>> or pilgrim route.
>
>
> Except that the correct name for such a chapel is "chapel of ease" not
> "chapel of rest."
>
>
>> OSM is a map for the whole world, and it does not improve acceptance when
>>
> a bunch of old white males (such as myself) chose a biased term for a
>> feature
>>
> that naturally exists in other cultural/religious contexts as well.
>
>
> Do other religions have such places?  If so, what do they call them?  And
> can we then abstract a neutral name from that?
>
>
>> To close with an alternative, "mourning room" would be a neutral
>> alternative from my perspective, reflecting the process of mourning which I
>> suppose exists in all cultures.
>>
>
> I object to room being applied to a building which may have many such
> rooms.
> I'd have less of a problem with amenity=mourning.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - (Chapel of rest)

2020-11-04 Thread Peter Elderson
woll...@posteo.de:
> 
> Dear all,
> 
> ...someone who has died before their funeral

I should hope so

> ___
> 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] Parking fee only after some time period

2020-10-21 Thread Peter Elderson
towing_penalty=no means your car is towed away for free? In Nederland, towing 
always comes with a penalty, even if you don't want your car back.

Maybe a tag for consequences should be introduced. I suggest or_else=cargone.

Best, Peter Elderson

> Op 21 okt. 2020 om 10:32 heeft stevea  het 
> volgende geschreven:
> 
> In California, a common (not quite frequent, certainly not always) 
> arrangement at malls, supermarkets and other places with parking lots (large 
> and small) is a sign that reads "you can park here for three hours, but after 
> that we have the right to tow your car away."  (Sometimes punctuated with 
> 'video surveillance active' to make the point fairly direct and that "they 
> mean business").  In my experience of driving-and-parking for many decades, I 
> personally have never gotten towed (the few times I've gone over a time 
> limit), I've never heard of anybody (that I personally know) getting towed, 
> but I have seen the extremely infrequent tow truck towing a car that has 
> likely been there a while — perhaps it was abandoned, used for illegal 
> purposes or was otherwise a public nuisance.
> 
> So, while that "moderately serious consequence" of getting towed is possible, 
> it's rare.  And, while this is not a "fee," it certainly turns into a fairly 
> large one once the bottom-line-costs, tow truck driver and storage charges 
> (per day, usually) are added together and paid to get one's car back from the 
> impound lot.
> 
> If you are writing a proposal, this is a reality in certain parts of the 
> world the proposal should consider, if it wants to convey the full situation 
> (on Earth, in cars, with humans, on parking lots).  In short, what appears to 
> be "simply" a fee can be fairly full-throated when it comes to describing the 
> entire semantic richness of the situation.
> 
> A tag like maxstay is a good beginning.  An additional tag of something like 
> towing_penalty=yes|no is a start down this road.
> 
> SteveA
> ___
> 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] Proposal to change key:man_made to key:human_made

2020-10-19 Thread Peter Elderson
Or, let's acknowledge that many distinctions are pointless because an awful lot 
of primary keys just mean "thing", so the key does not really matter, only the 
value counts. Who cares what the *  in *=bus_stop says, it's a bus stop.

Peter Elderson

>> Op 19 okt. 2020 om 19:43 heeft Martin Koppenhoefer  
>> het volgende geschreven:
> 
>> Am Mo., 19. Okt. 2020 um 15:04 Uhr schrieb Dave F via Tagging 
>> :
>> I mean, *everything* is either man made or natural. 
> 
> 
> 
> if we push this forward, humans are part of the natural world as well. Lets 
> get rid of these dichotomies, and strive for a unified vision of the world, 
> where human and nature aren't opposing poles but where the humans live in and 
> with the nature, as part of it.
> 
> And yes, if we are moving away from "man made" we can at this point also have 
> a look how the objects under this key could be organized better. I agree that 
> "artificial" would not be beneficial in this context, but rather a renaming 
> with the same issues (or even worse, think of things like "man_made=works", 
> wouldn't it be horrible to have "artificial=works"?)
> 
> 
> 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] Proposal to change key:man_made to key:human_made

2020-10-19 Thread Peter Elderson
Another illusion shattered... where is this world going to?

Best, Peter Elderson

> Op 19 okt. 2020 om 13:48 heeft Jo  het volgende 
> geschreven:
> 
> 
> It would be best to first consider the consequences of such a change. Weigh 
> the benefits against what we lose in time (humanhours?) and resources/energy. 
> And then there is still the point that many objects will get new timestamps 
> for a change that's not really a change.
> 
> Anyway, artificial sounds like made up to me. artificial=dyke, not really a 
> dyke, but it looks like it.
> 
> man_made has the advantage of being succinct. Most people will immediately 
> understand what is meant by it. Almost nobody will think women were not 
> involved in the creation of the feature.
> 
> Polyglot
> 
>> On Mon, Oct 19, 2020 at 12:42 PM Robert Delmenico  wrote:
>> Nice investigating Nathan,
>> 
>> I would be open to using artificial instead of human_made.
>> 
>> 
>> Would it be best to change the proposal or start a second proposal?
>> Change man_made= to artificial=
>> 
>> Rob
>> 
>> 
>>> On Mon, 19 Oct 2020 at 21:14, nathan case  wrote:
>>> Pros and cons aside, “human-made” is not a term that is in current 
>>> widespread usage. As a native English GB speaker, I find it clunky and 
>>> somewhat distracting.
>>> 
>>> A better gender neutral term might be “artificial”, which is already a 
>>> synonym for “man-made” and is already widely used. 
>>> 
>>> Indeed, the Handbook of Nonsexist Writing suggests: "artificial, handmade, 
>>> hand-built, synthetic, manufactured, fabricated, machine-made, and 
>>> constructed" as options instead of man-made. Presumably the majority (if 
>>> not all) of OSM "man-made" tags relate to objects which are not naturally 
>>> occurring. Therefore "artificial" seems to hold.
>>> 
>>> Other sources: 
>>> https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/ 
>>> https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
>>> https://dictionary.cambridge.org/dictionary/english/man-made
>>> 
>>> An issue may arise if artificial is already being used as a tag however.
>>> 
>>> Best,
>>> 
>>> Nathan
>>> ___
>>> 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] Battery swapping spot in a charging station or being an individual tag?

2020-10-06 Thread Peter Elderson
Would that be a new sub-tag or a value of an existing sub-tag?

Best, Peter Elderson


Op di 6 okt. 2020 om 09:27 schreef Jez Nicholson :

> Myself, I would prefer *not* to have a new tag. Swapping a battery is a
> form of recharging and can be detailed in a subtag.
>
> On Tue, 6 Oct 2020, 04:51 德泉 談 via Tagging, 
> wrote:
>
>> When my e-scooter run out of energy I would go to the swapping stations
>> to have a new battery since the battery must be rented by the battery
>> provider.
>>
>> It just like charging the battery in very short time (even faster than
>> refueling in the gas station). But it truly more like to have a new bottled
>> gas when my kitchen runs out of fuel.
>>
>> Due to the requirement of a large power system, sometimes battery
>> swapping station and charging station are located at the same place.
>>
>> - Tan
>>
>> 於 星期二, 10月 6, 2020, 5:34 上午,Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> 寫道:
>>
>> Oct 5, 2020, 18:58 by tagging@openstreetmap.org:
>>
>> Hi All,
>>
>> I want to write a new proposal about the battery swapping system for the
>> automotive vehicle. I'm not sure if modifying amenity=charging_station is
>> better or creating a new tag amenity=battery_swapping. I prefer to use
>> amenity=charging_station but found that is not a easy thing to do that.
>>
>> In case of a new tag - what would happen with place that offers both
>> charging and battery swapping?
>>
>> I wonder how such swap battery station acts from viewpoints of user -
>> is it functionally an equivalent to a very fast charging station?
>>
>> ___
>> 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 - (shop=direct marketing)

2020-10-03 Thread Peter Elderson
Is it private sale?

Vr gr Peter Elderson


Op za 3 okt. 2020 om 23:37 schreef Graeme Fitzpatrick :

>
>
>
> On Sun, 4 Oct 2020 at 00:39, Paul Allen  wrote:
>
>>
>> More important is if there is a sign,
>>
>
> Hand-painted signs saying "Horse manure", "Avo's", "Firewood", "Eggs" & so
> on good enough?
>
> We see lot's of them whenever we go for a drive in the country, & even the
> occasional one in town!
>
> shop=farm_gate would work for those stalls set up literally at the farm's
> front gate, but not sure about the ones in town such as
>
> https://www.google.com.au/maps/@-28.0794558,153.4353269,3a,44.3y,353.08h,84.13t/data=!3m6!1e1!3m4!1srvTirWlBxaboKXGY_z4YiQ!2e0!7i16384!8i8192?hl=en
> (Sorry, there's a bus in the way! but the sign says "Horse manure for
> sale")
> or
>
> https://www.google.com.au/maps/@-28.0830057,153.4348792,3a,19.6y,207.92h,79.69t/data=!3m6!1e1!3m4!1stYPeGpJj91C6jw_hQGFTZA!2e0!7i13312!8i6656?hl=en
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

2020-10-03 Thread Peter Elderson
I think for tagging it should be more than the occasional road-side sale?

Best, Peter Elderson


Op za 3 okt. 2020 om 14:38 schreef Paul Allen :

> On Sat, 3 Oct 2020 at 13:22, Martin Koppenhoefer 
> wrote:
>
>>
>> shop=* seems ok for me.
>
>
> And for me.  There are "formal" shops which open only 2 days a week.  Or
> have limited hours.  Or surly staff.  You go there and buy stuff, it's a
> shop.
>
>
>> Maybe “game” would be ok as value.
>>
>
> I think not.  Too easy to confuse "game" and "games."  Better to use
> shop=butcher + produce=game.
>
> --
> 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] "width" on streets: Time for a recommendation

2020-09-29 Thread Peter Elderson
What about the many streets and roads where the kerb or lining is bended
and curled to cut the parking lane into sections?

Best, Peter Elderson


Op di 29 sep. 2020 om 11:40 schreef Supaplex :

> Now I am a little confused.
>
> As I understand Pieter, you used "width:carriageway" in Bruges in a way
> that includes parking:lanes (although you can estimate later how much is
> effectively not available for flowing traffic if using parking:lanes).
>
> My initiative for a clarification of the tagging was motivated among other
> things to find a distinction between width *with* and *without* parking
> lanes in order to not only indirectly estimate the effective width but to
> measure it directly. Personally, I had understood "width:carriageway" to
> mean only the effective width available for flowing traffic. But maybe this
> is exactly the right term for the measurement from curb to curb and we
> still need a new term for the effective width ("width:traffic_area")? Or is
> it anyway illusory to specify the effective width of a roadway, because it
> has no "fixed limit" (parking cars are changeable) and you can only
> estimate it anyway by a combination with "parking:lane"...?
>
> I think it would be helpful to be able to specify an effective width if
> needed. After all, this is the most interesting parameter for assessing the
> quality/usability of a street. Even with a full parking:lane-tagging the
> estimation is worse than simply measuring it directly. For example, in the
> case of "half_on_kerb" parking it is not clear to assume that exactly half
> the average vehicle width is "lost" on the carriageway - sometimes there is
> only one tire on the sidewalk and two thirds of the vehicle occupies the
> roadway. Also global assumptions for the loss of width when parking
> "diagonal" or "perpendicular" seem unrealistic to me. De facto, parking
> lanes almost always occupy a constant area, and the effective width of the
> carriageway can be specified to within a few decimeters on site or on
> aerial photographs.
> What do we do now? My (new) suggestion: "width:carriageway" means the
> total road width from curb to curb or from edge to edge of the road
> surface. "width:traffic_area" (or another suitable term; so far nothing
> comparable is in use as far as I see) could be used to indicate the
> effective width available for flowing traffic.
>
> Alex
>
>
> Am 27.09.20 um 22:47 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>
> On 27. Sep 2020, at 13:45, Pieter Vander Vennet  
>  wrote:
> This width was tagged with 'width:carriageway'.
>
>
> I think this is a good tagging decision, being explicit about which width you 
> have measured seems the way to avoid ambiguity. (and it still leaves room for 
> the next project which could measure sidewalk widths ;-) ).
>
> Cheers Martin
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] [Talk-us] Large fire perimeter tagging?

2020-09-27 Thread Peter Elderson
Clifford Snow :

> I'm not sure there would be a consensus agreement to revise the wiki to
> indicate landuse=forest should be used for timber production.  Thoughts?
>

I am sure there would not. landuse=forest just means the area has trees. I
think there is some consensus about that.
natural=forest: same.
The idea that natural=wood is for natural woods and landuse=forest is for
managed forests has too little practical support.
Since there is no consensus about other aspects than "there are trees",
data users and renderers will stick to 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] Feature Proposal - RFC - (Chapel of rest)

2020-09-27 Thread Peter Elderson
Funeral viewing room sounds like a room where you can view the funeral. I 
suspect modern ones have very large screens and nice sound effects.

Mvg Peter Elderson

> Op 27 sep. 2020 om 19:39 heeft woll...@posteo.de het volgende geschreven:
> 
> "In any case, the proposer seems to feel that chapel of rest
> should be used only for dedicated buildings and a different
> tag should be added to indicate a funeral director's with a
> viewing room."
> The proposer feels that a subtag should be used for a funeral director's with 
> a viewing room. But the proposer's preference goes to using the same term for 
> the amenity tag and for the subtag (examples given in the proposal).
> 
> At the same time, may I ask for comments on "funeral viewing rooms"? Apart 
> from its length, it only seems to have advantages.
> 
> Am 27.09.2020 13:55 schrieb Paul Allen:
>> On Sun, 27 Sep 2020 at 10:02, Michael Patrick 
>> wrote:
>>>>>> From: Paul Allen 
>>>>> Problem 1. "Viewing Service" is the name of a process, not the
>>>> name
>>>>> of the building or room it takes place in. "Turn left after
>>>> the Viewing
>>>>> Service" > makes no sense, any more than "Turn right after the
>>>> prayer" as an alternative to "Turn right after the church."
>>> Mmmm  I agree, that's my point. 'Chapel of Rest' isn't a place,
>>> at best it
>>> sometimes might be a dedicated room in a funeral establishment.
>>> Apparently,
>>> it is not infrequently the showroom for caskets if a larger
>>> attendance needs to
>>> be accommodated.
>> It may be as you state it in some cases.  It is not true of all.
>> Here's
>> one where the chapel of rest is a building solely for that purpose:
>> https://www.colinphillipsfunerals.com/our-services/private-chapel/ [6]
>> That does not serve any other purpose.  It is not his offices or
>> showroom.  I know of another one like that a few miles from it.
>> Also, a chapel, even in the religious sense, is not necessarily a
>> separate building.  It originally referred to a small room within
>> a church with its own altar, or a room with an alta in a
>> non-religious building.
>> In any case, the proposer seems to feel that chapel of rest
>> should be used only for dedicated buildings and a different
>> tag should be added to indicate a funeral director's with a
>> viewing room.
>>>>> Problem 2. "Viewing service" implies some sort of formalized
>>>> event,
>>>>> probably religious with a speaker delivering a eulogy. A
>>>> Chapel of
>>>>> Rest is for looking at a dead body, with no formal ceremony.
>>>> Possibly
>>>>> in complete silence. Possible with only one live person in the
>>>> room.
>>>>> Contrast this with a religious service, which has prayers,
>>>> hymns,
>>>>> a sermon, bouts of kneeling, etc.
>>> Connotation of 'service' as in 'floral service', embalming service',
>>> 'cremation service' or otherwise business task / activity like
>>> 'automotive repair service', rather than the religious service
>>> denotation like a mass.
>> I wouldn't expect a religious service at a florist or a car mechanic.
>> When it comes
>> to funerals, however...
>>> From the US Federal Trade Checklist at
>> https://www.consumer.ftc.gov/articles/0301-funeral-costs-and-pricing-checklist
>>> [1]
>>> Visitation/viewing — staff and facilities __
>>> Funeral or memorial service — staff and facilities __
>>> Graveside service, including staff and equipment __
>> That's nice.  But it's not British English.  You can, however, use it
>> to argue that editor translations for US English should use visitation
>> for the preset name.
>>> UK funeral industry shows both 'Chapel of Rest', or that term with
>>> visitation / viewing, some just have 'venue rental'. CoR is fairly
>>> typical.
>> Precisely.  CoR seems to be the commonest term for it.  And less
>> ambiguous than "visitation" (people visit patients in hospitals) or
>> "viewing" (people view paintings in art galleries).
>>>>> Problem 3. I've not encountered that term as a synonym for a
>>>> chapel of
>>>>> rest. But I've not looked very hard. Citation needed.
>>> https://funeralresources.com/resources/viewing-and-visitation-costs/
>>> [2]
>>> https://funerals.org/?consumers=read-funeral-home-p

Re: [Tagging] Feature Proposal - RFC - (Chapel of rest)

2020-09-25 Thread Peter Elderson
I would suggest respectorium, but I do not want to start a new hype in the 
funeral branch. 

Mvg Peter Elderson

> Op 25 sep. 2020 om 17:10 heeft woll...@posteo.de het volgende geschreven:
> 
> "Wake rooms" was at one time my favorite, but then I was told that some 
> people might associate "wake" with a particular denomination as well.
> 
> I'm not a native speaker either, so I can't judge.
> 
> Something with "viewing" might be nice as well; "funeral viewing room" 
> (between quotation marks) yields some interesting results on Google. A bit 
> long, but at this point, I'd take that as a minor incovenience.
> 
> Am 25.09.2020 15:09 schrieb Martin Koppenhoefer:
>> sent from a phone
>>>> On 25. Sep 2020, at 00:51, Michael Patrick  wrote:
>>> ( I once went to one in Detroit, where the open casket and reception line 
>>> was right there with tables of people eating brunch ('wake')).
>> so it could be “wake_room”?
>> Now this might sound a tad euphemistic as well, but search engines
>> actually restitute pertinent results.
>> 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


Re: [Tagging] Linking Sidewalks to Highways

2020-09-22 Thread Peter Elderson
Jeroen Hoek :

> I have been applying highway=cycleway + cycleway=link as well to see how
> this feels. Some early documentation I have been preparing:
>
> https://wiki.openstreetmap.org/wiki/User:JeroenHoek#cycleway.3Dlink
>

Why the diagonal link to the center intersection node?
Wouldn't it be more logical / practical to continue the cycleways straight
up to the way of the crossing road?
No link tag needed there, I think.





> ___
> 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 - (Chapel of rest)

2020-09-21 Thread Peter Elderson
I have heard mourning chapel, mourning room, funeral chapel, funeral room.
Chapel of rest does not seem right to me, though I understand how the
funeral business would like that term better.

But I'm not a native speaker. PCMIIW.

Peter Elderson


Op ma 21 sep. 2020 om 21:14 schreef :

> Dear all,
>
> As already mentioned, another ripple effect of my first proposal has
> materialised, the need to be able to properly tag chapels of rest as
> well.
>
> Therefore please comment on the following proposal:
>
> Chapel of rest: a room or building where families and friends can come
> and view someone who has died before their funeral
>
> Proposal page:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest
> Discussion page:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest
>
> Thanks!
>
> Vollis
>
>
> ___
> 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] Linking Sidewalks to Highways

2020-09-21 Thread Peter Elderson
So we need a way to determine the crossability of a road for walkers and 
cyclists, probably using a combination of highway value of the crossed way, 
maybe the access tag (foot=yes probably can be crossed on foot) and some 
indicator tag for crossing access (foot:crossing=yes/no ?) to tag exceptions.  

Currently I do map short footways/paths where I know pedestrians will cross the 
road, even when no physically marked crossing exists. Opposite lowered kerbs or 
the fact that nearby dirt paths exists at both sides, not too far apart, 
already is a luxury.

Mvg Peter Elderson

> Op 21 sep. 2020 om 14:57 heeft Paul Allen  het volgende 
> geschreven:
> 
> 
>> On Mon, 21 Sep 2020 at 11:06, Supaplex  wrote:
>> 
> 
>> The problem remains that physically non-existent road crossings ("wildly 
>> crossing the street"), which in reality represent a crossing possibility for 
>> many users, are still not available for routing. In my opinion, this problem 
>> is not very relevant if separate way"  are well mapped (which they often are 
>> unfortunately not!) and all essential routable connections are in the 
>> database. At the beginning and at the end of the route, people can use their 
>> brains ("destination across the street") if their routers do not solve this 
>> task for them.
> 
> This isn't as simple as you make out.  Assume that I am at point A and wish to
> go to point B, which involves a "wild crossing" at some point between the two.
> However, there is a real crossing at point C, a mile beyond point B,  A router
> will direct me to travel to point C (a mile further than my destination) in 
> order
> to cross the road there, so I can then walk a mile back to B.
> 
> -- 
> 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] Powerbank Sharing Systems

2020-09-19 Thread Peter Elderson
Wouldn't that just duplicate the location systems they offer? And on top of
that,  a sizable maintenance burden to keep up with the changes? Who is
going to want this on OSM after committing to a chain?

Best, Peter Elderson


Op za 19 sep. 2020 om 13:02 schreef Jake Edmonds via Tagging <
tagging@openstreetmap.org>:

>
> https://commons.wikimedia.org/wiki/Category:Powerbank-sharing_systems_by_name
> https://heychimpy.com
> https://www.wecharge.me
>
>
> I can’t see any tagging related to powerbank sharing systems.
>
> Unless anyone can point me to existing tagging, I will submit a proposal,
> based on amenity=bicycle_sharing, titled amenity=powerbank_sharing for
> tagging docking station.
>
> Chimpy (linked above) appears to use docking stations and over-the-counter
> rentals. Should an additional tag, such as service:powerbank:rental=yes, be
> included for existing features?
>
> Thanks
> Jake
> ___
> 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] automated edits seem to remove crossing=zebra drastically

2020-09-18 Thread Peter Elderson
>
> Maybe crossing=marked + marked=???
> where ??? is the "type" of crossing - UK_zebra (as well as all their other
> birds & animals!), US_zebra, EU_zebra & so on, so if you know exactly what
> it is you can specify, but if you can only see a crossing marked there, you
> can just call it a marked crossing?
>

Isn't it obvious from the location what the country is?

Crossings can have all sorts of markings. Most markings just indicate that
it's a crossing, i.e. a preferred location for pedestrians to cross the
road. Those markings result in the *=crossing tag.

UK has a rich wildlife of crossings, but afaik all have controls except the
zebra, so you can tag the control if you think it's worthwhile.

Priority is regarded as a mappable attribute. It seems that, in many
countries, zebra striping is used to grant priority to pedestrians. If
mappers do not think crossing=zebra combined with the location is clear
enough about the priority, then I suggest to add a tag for priority.

In Nederland, zebra also implies drivers are not allowed to park on or
within a certain distance from the crossing. If that's deemed important and
should not just be implied by the zebra tag, it should be tagged on the
section of the road itself.

In Nederland, pedestrians are not allowed to cross the road near the zebra
within a certain distance (50 m or so).
This is important for pedestrian routing. I think this is handled already
by the presence of the way for pedestrians.  I may be wrong, but I believe
routing over a way is preferred to crossing wildly over a road.

In short, I think crossing=zebra says what you see, the implications can be
read from the country the location is in,  and if that's not sure enough
tag the implications separately and precisely.

Changing to crossing=marked then specifying that it's a zebra just makes it
more work, and harder to interpret.


Vr 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] automated edits seem to remove crossing=zebra drastically

2020-09-17 Thread Peter Elderson
In Nederland, the zebra is a very clear and specific type of crossing with
legal rules including yield to pedestrians walking on or even toward the
zebra.

I think this will continue to be the case even after Europe leaves the
British Union.

Vr gr Peter Elderson


Op do 17 sep. 2020 om 20:12 schreef Matthew Woehlke <
mwoehlke.fl...@gmail.com>:

> On 17/09/2020 13.44, Tod Fitch wrote:
> >> On Sep 17, 2020, at 9:30 AM, Matthew Woehlke wrote:
> >> On 17/09/2020 10.07, Shawn K. Quinn wrote:
> >>> On 9/17/20 08:15, Matthew Woehlke wrote:
> >>>> It's also atrocious because it can *only* be verified by survey. As
> >>>> much as we prefer surveys, the reality is that a lot of mapping
> >>>> happens just from aerials, where crossings (both marked and, in some
> >>>> cases, unmarked) can be seen, but signals cannot.
> >>> I have mapped many traffic signals (and, for that matter, stop and
> yield
> >>> signs) based on shadows visible on the satellite photos. If you look
> >>> carefully enough (Bing and Mapbox Satellite at least), they are there.
> >>> (Local knowledge helps too in some cases.)
> >>
> >> *Traffic* lights I can buy. I am more suspicious of the claim that
> >> you can tell whether they have pedestrian crossing signals or not,
> >> or that you can reliably identify other signage based solely on
> >> outline. *Maybe* if you get lucky and have a very clear shadow at
> >> the right angle, but if you try to tell me you can identify
> >> https://www.openstreetmap.org/node/7695704414 (n.b. a yield sign)
> >> from a shadow in aerial imagery, I am going to be deeply suspicious
> >> ;-).
> >
> > Not from the signs or shadows of the signs, but in my area the
> > pavement markings can often tell you if it is a stop or yield. Some
> > times it is easy (“STOP” or “YIELD” painted on the pavement). But it
> > seems that newer road work uses a different style limit line for a
> > stop versus yield.
>
> Ah, that's fair; I was under the impression we were talking about
> *signs*. Possibly because most of the yields I see are to yield to other
> *vehicles*, not pedestrians. (I *have* seen "yield to pedestrians", now
> that I think about it, but not sure I've ever seen *lane markings* where
> it's clear that what you are supposed to yield for is pedestrians. Other
> than crosswalks, anyway. Which... makes me wonder if
> "crossing=uncontrolled" is even correct; even more reason to not use
> that! My understanding was "uncontrolled" meant by traffic signals, but
> now I'm not so sure.)
>
> I've tagged some yields based on lane markings myself, e.g.
> https://www.openstreetmap.org/node/7714853074.
>
> > Back to the original topic: I am not really sure what, if any, the
> > US version of a “zebra" crossing is versus a “marked” crossing. So I
> > usually just tag as “marked” as that seems to be the more generic
> > item.
>
> Likewise. Even the wiki notes that this is unclear "outside the UK" (as
> I previously observed).
>
> > The crossing you linked to *might* be an example of a US “zebra”
> > crossing. Can anyone verify that for me. Also, there are no tags on
> > the intersection node itself. Should there be? I have assumed that
> > there should so that vehicle based navigation would have the
> > information needed to advise the driver of particular type of
> > crossing ahead.
>
> As I understand it, yes, and I've tagged that in other places (e.g. the
> above example). I actually have no idea why that node is marked as a
> yield; I don't think there's actually a yield there, but I'm hesitant to
> just delete it (even though apparently I'm the one that added it).
> Unfortunately I can't go survey it right now. (Have to try to remember
> to do that when/if I ever make it back to that Cracker Barrel :-).)
>
> --
> Matthew
>
> ___
> 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] automated edits seem to remove crossing=zebra drastically

2020-09-16 Thread Peter Elderson
In Nederland zebra crossings are very common, and go by the name zebra.This is 
also the name used in legislation. Zebra crossings give priority to pedestrians 
crossing the street on the zebra. Hm how should this be tagged... maybe 
crossing=pathtocrosstheroadmarkedwithstripeslikeazebratograntprioritytopedestrians?

Peter Elderson

>> Op 16 sep. 2020 om 23:47 heeft Graeme Fitzpatrick  
>> het volgende geschreven:
> 
> 
> 
>> On Wed, 16 Sep 2020 at 20:01, Martin Koppenhoefer  
>> wrote:
>> while the very generic crossing=marked, which was quite unpopular before 
>> (2013-2018 below 6000 uses) now went through the roof and is leading the 
>> tagstats with more than 1 million uses.
> 
> You may find that it is partly, at least, iD's "fault"? Crossings now "error" 
> in iD to say that "this street crosses an unmarked crossing", despite the 
> crossing being mapped & tagged? eg 
> https://www.openstreetmap.org/edit#map=19/-28.06439/153.43854
> 
> The "fix" inserts an "Unmarked Crossing" node on the junction of the street & 
> crossing.
> eg https://www.openstreetmap.org/node/7914347813
> 
>> What do you think about it, shouldn't we be encouraging people to use more 
>> specific tags like crossing=zebra or crossing=traffic_signals instead?
> 
> I must admit that I only do crossings as =traffic_signals; =marked (by 
> itself) for zebra crossings; & =unmarked where there is provision to cross 
> the road but no signage or roadway markings on any sort.
> 
> 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] Tagging for board games themed pubs

2020-09-12 Thread Peter Elderson
I would tag board_games=* for the availability of board_games at the venue.
Values: yes, no, or a colon separated list of available games.

For theme meaning style, maybe simply style=*, or pub_style=*, or
pub:style=*,

For theme meaning the specialty or focus: specialty=* or focus=* or the
like.

I'm not sure how to tag solar terrace orientation and terrace cover type,
though

Vr gr Peter Elderson


Op za 12 sep. 2020 om 11:01 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> 12 Sep 2020, 00:50 by graemefi...@gmail.com:
>
>
>
> On Fri, 11 Sep 2020 at 22:06, Niels Elgaard Larsen 
> wrote:
>
> Mateusz Konieczny via Tagging:
>
> > A lot of pubs have board games available for customers to play, or
> they did in
> > normal times.
>
>
> How about pubs that host trivia games one night a week?
>
> I think it is clearly not a board game.
>
>
>
> could we have something like board_games=yes/no/permitted/designated ?
>
>
> But if it's =no, would that mean that you can't pull out a pack of cards &
> have a game of solitaire?
>
>
> 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] Tagging for board games themed pubs

2020-09-11 Thread Peter Elderson
Focus?

Mvg Peter Elderson

> Op 11 sep. 2020 om 20:40 heeft Paul Allen  het volgende 
> geschreven:
> 
> 
>> On Fri, 11 Sep 2020 at 19:09, Martin Koppenhoefer  
>> wrote:
> 
>> > Themed implies that is the raison d'etre for the pubs existance and you 
>> > would only go there to play board games, which would attract a very 
>> > limited clientel.
>> 
>> +1, this is also my interpretation.
> 
> Not my interpretation of "theme."  Most pubs I've been in, themes have
> been about decor.  Like the pub named "Walpurgisnacht" and decorated
> accordingly, but there were no battles against witchcraft there.  Like
> the pub with many shelves of books, which nobody read.  Like
> the pub with a fake tree built into a corner.  Like the pub called The
> Buccaneer, decked out [pun intended] as a sailing ship, but there
> were no acts of piracy.
> 
> "Theme" is the wrong word to use.  A pub with many pool tables
> is not themed around playing pool.  A pub with many dart boards
> for practise by its darts team is not themed around darts.  Right
> now I can't think of a good word for a pub specializing in a
> particular interest (many pool tables rather than just one), but
> "theme" isn't 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] Rail segment in a bike route

2020-08-31 Thread Peter Elderson
Volker Schmidt :

> The double role issue, if it occurs, is there in either case, separate
> relation or role in the bicycle route relation.
>

If a way or a chain of ways in a route relation has no
forward/backward role,  you can assign it a transfer/transport role.Easy
for e.g. ferries operating in both directions.

If the bicycle has split directions and transfer/transport is also
different for the travel directions, I think a route_master relation is
needed for the transfer. The superroute will have as members: the bicycle
relation up to the transport; the routemaster relation with the
transfer role, and the section of the bicycle route at the other side of
the transfer.

I think for most bicycle routes this kind of transfer will have a shared
way or shared point near the transport. So I think this will not happen
very often.But if it does, tagging can be done as described above without
ever having to combine roles. Processing is another matter, though.


> Regarding travel details of ferry/rail/bus sections within bicycle routes:
> This information, if available, should go on the the ferry/rail/bus route
> relations, as these means of transport are not exclusive to the bike route,
> at least in most cases, and therefore should have their own relations
> independently of bicycle travel.
>
> In more general terms, this intermodal transport problem is a big black
> hole in OSM in general. The commercial competition is spending a lot of
> money in that sector. I am not sure we can or even want to compete with
> that.
>

 The development is instant point-to-point routing over different
networks and transport modes. Route relations pre-combine elements to
form a fixed route for a particular  purpose, e.g. a theme or named trail
to be followed exactly. I don't think roles in fixed route relations will
solve the instant routing challenge!


> On Mon, 31 Aug 2020 at 09:53, Peter Elderson  wrote:
>
>> Jo:
>>
>>> I added that it's not needed for ferries in the proposal on the wiki.
>>> It's alright if we have more than 1 way to do it and leave it up to the
>>> mapper to decide whether to map as a single route relation or split them
>>> and use a superroute relation.
>>>
>>
>> Wouldn't this apply to other transfer/transport sections as well?
>>
>>
>>> If I start doing a bicycle tour, I want to know in advance if I'll be
>>> able to cycle the whole stretch, or if there will be waiting time for other
>>> means of transportation. I would also like to know if there will be a fee
>>> to pay for these means of transportation and whether it's necessary to
>>> hurry, in case there is only 1 per x hours, or they don't function at
>>> night. By using separate route relations, it becomes possible to add
>>> opening hours and a frequency/period on them.
>>>
>>
>> Wouldn't this apply to ferries as well?
>> _
>>
>>> 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] Rail segment in a bike route

2020-08-31 Thread Peter Elderson
Jo:

> I added that it's not needed for ferries in the proposal on the wiki. It's
> alright if we have more than 1 way to do it and leave it up to the mapper
> to decide whether to map as a single route relation or split them and use a
> superroute relation.
>

Wouldn't this apply to other transfer/transport sections as well?


> If I start doing a bicycle tour, I want to know in advance if I'll be able
> to cycle the whole stretch, or if there will be waiting time for other
> means of transportation. I would also like to know if there will be a fee
> to pay for these means of transportation and whether it's necessary to
> hurry, in case there is only 1 per x hours, or they don't function at
> night. By using separate route relations, it becomes possible to add
> opening hours and a frequency/period on them.
>

Wouldn't this apply to ferries as well?
_

> 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

2020-08-31 Thread Peter Elderson
'transport' role, 'transportation' role ... is this in use and
documented somewhere?

In bicycle routes, when the ways are different for the two directions,
forward and backward roles apply to the ways in the relation.  If a
transfer/transport/transportation is to be applied as well, how would you
combine this? Multiple roles are currently not defined.

Vr gr Peter Elderson


Op ma 31 aug. 2020 om 08:16 schreef Warin <61sundow...@gmail.com>:

> On 31/8/20 8:25 am, Volker Schmidt wrote:
> > Keep it simple, if the simple solution does not limit you.
> >
>
> Agreed. I see no reason why a way as a member of a simple route relation
> could not have the role 'transport'.
>
>
>
> ___
> 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

2020-08-30 Thread Peter Elderson
Route hierarchy is regular practice.The parent relation holds child
relations. This is the case for many types of route,

As far as I can see, there are two new elements:

1. A child relation (route section) can be of a different route type.
2. Provided it has a special role

Since the type is in the child relation, you don't need to specify that in
the role.

This is valid for many route types. I would suggest not to present it as a
complex bicycle route, but as a way to incorporate transfer sections of
different types in routes of any transport type.

Best, Peter Elderson


Op zo 30 aug. 2020 om 17:52 schreef Jo :

> Hi Francesco,
>
> I started a proposal on the wiki:
>
> https://wiki.openstreetmap.org/wiki/More_complex_cycle_routes
>
> It will probably need to be moved to the proposal name space, but we can
> work on it over there before putting it up for a vote.
>
> Jo
>
> On Sun, Aug 30, 2020 at 3:09 PM Francesco Ansanelli 
> wrote:
>
>> I saw your changes... LGTM.
>> Thanks!
>> It would be great to have a page to document your proposal.
>> Cheers
>> Francesco
>>
>> Il dom 30 ago 2020, 12:03 Jo  ha scritto:
>>
>>> Hi Francesco,
>>>
>>> I will create the superroute and route relations as an example. If you
>>> don't like the solution, feel free to remove those relations again
>>> afterwards. I will only fix a small error in the original relation, but
>>> keep it for now, so both solutions can be analysed next to each other.
>>>
>>> I don't really like the idea of a role 'transfer' on all those railway
>>> ways in a single route relation. In the case of your example, there is only
>>> a single railway, but in theory there could be one for each direction of
>>> travel of the train. So if you want to describe that in the route relation,
>>> you would need role forward/backward in the route relation, which cannot be
>>> combined with role transfer.
>>>
>>> Jo
>>>
>>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli <
>>> franci...@gmail.com> wrote:
>>>
>>>> Dear Polyglot,
>>>>
>>>> it sounds good to me. But what roles do you suggest for such superroute?
>>>> Many thanks
>>>> Francesco
>>>>
>>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>>> scritto:
>>>>
>>>>> How would you feel about mapping it with a superroute relation?
>>>>>
>>>>> The superroute would then contain 3 route relations.
>>>>>
>>>>> 1 for the first part by bicycle
>>>>> 1 for the middle part by train
>>>>> 1 for the last part by bicycle
>>>>>
>>>>> If we give the train part a different role in the superroute, we can
>>>>> make it such that the continuity line in JOSM is still drawn.
>>>>>
>>>>> This solution might also work to indicate that certain parts of a
>>>>> bicycle route need to be done on foot. Although creating separate route
>>>>> relations for such short stretches may feel like overkill.
>>>>>
>>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>>> it's unlikely we'll create a route relation for this, but not
>>>>> impossible/unthinkable).
>>>>>
>>>>> In JOSM PT_Assistant there will soon be a convenience button to
>>>>> extract route relations from route or superroute relations, to make a
>>>>> conversion from route to superroute+route relations easier to do.
>>>>>
>>>>> Polyglot
>>>>>
>>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>>> franci...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> a new example that could benefit of this proposal:
>>>>>>
>>>>>> https://www.openstreetmap.org/relation/10605853
>>>>>>
>>>>>> Can someone please go ahead and make a proposal?
>>>>>>
>>>>>> Many thanks
>>>>>> Best regards
>>>>>> Francesco
>>>>>>
>>>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  h

Re: [Tagging] Rail segment in a bike route

2020-08-30 Thread Peter Elderson
To clarify: the transfer role could be added to the role value list:

*None* or main The role value for the main section(s) of a signposted or in
any way waymarked route.
alternative A signposted or otherwise waymarked alternative branching off
then rejoining the main route at a significantly different point. The
alternative is used instead of a section of the main route.
excursion A signposted or otherwise waymarked side track which rejoins the
main track at or close to the same point where it left, e.g. to visit a
place of interest. The excursion is an optional addition to the main route.
approach Signposted or otherwise waymarked access route to or from
transport infrastructure e.g. parking, train station, bus station, cable
car. An approach is used in addition to the main route.
connection Signposted or otherwise waymarked link route from one
recreational route to another recreational route and vice versa. A
connection is used to switch from one route to another. Note that an
approach might act as a connection, e.g. when it ends/begins at a major
train station where other routes also pass through. In that case, use the
role approach.

Given this definition, the connection should appear in both routes involved.
*| transfer | Route section where a different mode of transport is
necessary, e.g. cable car transfer in a hikingh trail, train transfer in a
bicycle route, bus transfer through a tunnel. A transfer section is an
integral part of the route. |*

Best, Peter Elderson

Op zo 30 aug. 2020 om 12:47 schreef Peter Elderson :

> True. In that case, a transfer relation in a superroute is necessary. Like
> all the other roles: do not combine these roles on ways with with
> forward/backward, use a relation instead.
>
> Vr gr Peter Elderson
>
>
> Op zo 30 aug. 2020 om 12:06 schreef Jo :
>
>> Hi Francesco,
>>
>> I will create the superroute and route relations as an example. If you
>> don't like the solution, feel free to remove those relations again
>> afterwards. I will only fix a small error in the original relation, but
>> keep it for now, so both solutions can be analysed next to each other.
>>
>> I don't really like the idea of a role 'transfer' on all those railway
>> ways in a single route relation. In the case of your example, there is only
>> a single railway, but in theory there could be one for each direction of
>> travel of the train. So if you want to describe that in the route relation,
>> you would need role forward/backward in the route relation, which cannot be
>> combined with role transfer.
>>
>> Jo
>>
>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
>> wrote:
>>
>>> Dear Polyglot,
>>>
>>> it sounds good to me. But what roles do you suggest for such superroute?
>>> Many thanks
>>> Francesco
>>>
>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>> scritto:
>>>
>>>> How would you feel about mapping it with a superroute relation?
>>>>
>>>> The superroute would then contain 3 route relations.
>>>>
>>>> 1 for the first part by bicycle
>>>> 1 for the middle part by train
>>>> 1 for the last part by bicycle
>>>>
>>>> If we give the train part a different role in the superroute, we can
>>>> make it such that the continuity line in JOSM is still drawn.
>>>>
>>>> This solution might also work to indicate that certain parts of a
>>>> bicycle route need to be done on foot. Although creating separate route
>>>> relations for such short stretches may feel like overkill.
>>>>
>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>> it's unlikely we'll create a route relation for this, but not
>>>> impossible/unthinkable).
>>>>
>>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>>> route relations from route or superroute relations, to make a conversion
>>>> from route to superroute+route relations easier to do.
>>>>
>>>> Polyglot
>>>>
>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>> franci...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> a new example that could benefit of this proposal:
>>>>>
>>>>> https://www.openstreetmap.

Re: [Tagging] Rail segment in a bike route

2020-08-30 Thread Peter Elderson
I think the transfer section only needs the role transfer. The exact way of
transport there is tagged on the child relation which is a route in itself.
(type=route, route=*).

Peter Elderson


Op zo 30 aug. 2020 om 13:11 schreef Jo :

> I was in a hurry to go and eat and forgot to say this:
>
> In the Italian station, I added a footway through the station building and
> across the rails. That's not correct, of course. This should be improved
> with more detail. Is there a tunnel to cross the railway? A bridge? Do
> people have to risk it at an unsupervised level_crossing?
>
> If there is a tunnel or a bridge, most likely there is also a part with
> stairs.
>
> Possibly the train always arrives near the station building and never on
> the southern track as it is mapped now?
>
> I now added a role transfer in the superroute relation. Maybe a role
> transfer_on_foot, transfer_by_train, transfer_by_ferry,
> transfer_by_funicular would be more descriptive? For this we would need to
> create a proposal, but at the moment I'm mostly interested in your
> opinions. Creating a proposal and following up on it is a lot of work. I'm
> not sure if I have the stamina for it. But anyone can do it, so if you feel
> like it, go ahead.
>
> Jo
>
> On Sun, Aug 30, 2020 at 12:39 PM Jo  wrote:
>
>> I uploaded my way to solve this:
>>
>> https://www.openstreetmap.org/relation/11560387
>>
>> Polyglot
>>
>> On Sun, Aug 30, 2020 at 12:03 PM Jo  wrote:
>>
>>> Hi Francesco,
>>>
>>> I will create the superroute and route relations as an example. If you
>>> don't like the solution, feel free to remove those relations again
>>> afterwards. I will only fix a small error in the original relation, but
>>> keep it for now, so both solutions can be analysed next to each other.
>>>
>>> I don't really like the idea of a role 'transfer' on all those railway
>>> ways in a single route relation. In the case of your example, there is only
>>> a single railway, but in theory there could be one for each direction of
>>> travel of the train. So if you want to describe that in the route relation,
>>> you would need role forward/backward in the route relation, which cannot be
>>> combined with role transfer.
>>>
>>> Jo
>>>
>>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli <
>>> franci...@gmail.com> wrote:
>>>
>>>> Dear Polyglot,
>>>>
>>>> it sounds good to me. But what roles do you suggest for such superroute?
>>>> Many thanks
>>>> Francesco
>>>>
>>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>>> scritto:
>>>>
>>>>> How would you feel about mapping it with a superroute relation?
>>>>>
>>>>> The superroute would then contain 3 route relations.
>>>>>
>>>>> 1 for the first part by bicycle
>>>>> 1 for the middle part by train
>>>>> 1 for the last part by bicycle
>>>>>
>>>>> If we give the train part a different role in the superroute, we can
>>>>> make it such that the continuity line in JOSM is still drawn.
>>>>>
>>>>> This solution might also work to indicate that certain parts of a
>>>>> bicycle route need to be done on foot. Although creating separate route
>>>>> relations for such short stretches may feel like overkill.
>>>>>
>>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>>> it's unlikely we'll create a route relation for this, but not
>>>>> impossible/unthinkable).
>>>>>
>>>>> In JOSM PT_Assistant there will soon be a convenience button to
>>>>> extract route relations from route or superroute relations, to make a
>>>>> conversion from route to superroute+route relations easier to do.
>>>>>
>>>>> Polyglot
>>>>>
>>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>>> franci...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> a new example that could benefit of this proposal:
>>>>>>
>>>>>> https://www.openstreetma

Re: [Tagging] Rail segment in a bike route

2020-08-30 Thread Peter Elderson
True. In that case, a transfer relation in a superroute is necessary. Like
all the other roles: do not combine these roles on ways with with
forward/backward, use a relation instead.

Vr gr Peter Elderson


Op zo 30 aug. 2020 om 12:06 schreef Jo :

> Hi Francesco,
>
> I will create the superroute and route relations as an example. If you
> don't like the solution, feel free to remove those relations again
> afterwards. I will only fix a small error in the original relation, but
> keep it for now, so both solutions can be analysed next to each other.
>
> I don't really like the idea of a role 'transfer' on all those railway
> ways in a single route relation. In the case of your example, there is only
> a single railway, but in theory there could be one for each direction of
> travel of the train. So if you want to describe that in the route relation,
> you would need role forward/backward in the route relation, which cannot be
> combined with role transfer.
>
> Jo
>
> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
> wrote:
>
>> Dear Polyglot,
>>
>> it sounds good to me. But what roles do you suggest for such superroute?
>> Many thanks
>> Francesco
>>
>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>> scritto:
>>
>>> How would you feel about mapping it with a superroute relation?
>>>
>>> The superroute would then contain 3 route relations.
>>>
>>> 1 for the first part by bicycle
>>> 1 for the middle part by train
>>> 1 for the last part by bicycle
>>>
>>> If we give the train part a different role in the superroute, we can
>>> make it such that the continuity line in JOSM is still drawn.
>>>
>>> This solution might also work to indicate that certain parts of a
>>> bicycle route need to be done on foot. Although creating separate route
>>> relations for such short stretches may feel like overkill.
>>>
>>> The other 'interruption' of a bicycle route I can think of, is where a
>>> ferry needs to be taken. In theory this could also be a funicular. In
>>> Antwerpen there is a special bus service that takes cyclists through a
>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>> it's unlikely we'll create a route relation for this, but not
>>> impossible/unthinkable).
>>>
>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>> route relations from route or superroute relations, to make a conversion
>>> from route to superroute+route relations easier to do.
>>>
>>> Polyglot
>>>
>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> a new example that could benefit of this proposal:
>>>>
>>>> https://www.openstreetmap.org/relation/10605853
>>>>
>>>> Can someone please go ahead and make a proposal?
>>>>
>>>> Many thanks
>>>> Best regards
>>>> Francesco
>>>>
>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>>> scritto:
>>>>
>>>>> For the record, I think a transfer role is a generic solution  for the
>>>>> issue raised here, applicable to the cable car transfer and other types of
>>>>> transfer in routes, but I will not propose a new role value any time soon.
>>>>>
>>>>> Anyone who wants to do it has my support, though.
>>>>>
>>>>> Vr gr Peter Elderson
>>>>>
>>>>>
>>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>>> dieterdre...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> sent from a phone
>>>>>>
>>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>>> >
>>>>>> > Normal OSM access is assumed to be access=yes, where some access is
>>>>>> restricted then in OSM it should be marked *=no.
>>>>>>
>>>>>>
>>>>>> for roads access=yes is assumed, it is not necessarily the default
>>>>>> for all kind of features.
>>>>>>
>>>>>>
>>>>>> 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
>>>
>> ___
> 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

2020-08-30 Thread Peter Elderson
I suggest: role transfer for the transfer part.

The transfer part could be a route separate relation in a superroute, the
transfer type is given by the relation route type.
The transfer part could be a way or a chain of ways in a regular oute
relation, the transfer type is then determined by the tags of the ways.
editors, QA-tools and datausers would have to handle the role.

It fits in nicely with the accepted roles for recreational routes,
https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations


Best, Peter Elderson


Op zo 30 aug. 2020 om 11:26 schreef Francesco Ansanelli :

> Dear Polyglot,
>
> it sounds good to me. But what roles do you suggest for such superroute?
> Many thanks
> Francesco
>
> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
> scritto:
>
>> How would you feel about mapping it with a superroute relation?
>>
>> The superroute would then contain 3 route relations.
>>
>> 1 for the first part by bicycle
>> 1 for the middle part by train
>> 1 for the last part by bicycle
>>
>> If we give the train part a different role in the superroute, we can make
>> it such that the continuity line in JOSM is still drawn.
>>
>> This solution might also work to indicate that certain parts of a bicycle
>> route need to be done on foot. Although creating separate route relations
>> for such short stretches may feel like overkill.
>>
>> The other 'interruption' of a bicycle route I can think of, is where a
>> ferry needs to be taken. In theory this could also be a funicular. In
>> Antwerpen there is a special bus service that takes cyclists through a
>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>> it's unlikely we'll create a route relation for this, but not
>> impossible/unthinkable).
>>
>> In JOSM PT_Assistant there will soon be a convenience button to extract
>> route relations from route or superroute relations, to make a conversion
>> from route to superroute+route relations easier to do.
>>
>> Polyglot
>>
>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
>> wrote:
>>
>>> Hello,
>>>
>>> a new example that could benefit of this proposal:
>>>
>>> https://www.openstreetmap.org/relation/10605853
>>>
>>> Can someone please go ahead and make a proposal?
>>>
>>> Many thanks
>>> Best regards
>>> Francesco
>>>
>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>> scritto:
>>>
>>>> For the record, I think a transfer role is a generic solution  for the
>>>> issue raised here, applicable to the cable car transfer and other types of
>>>> transfer in routes, but I will not propose a new role value any time soon.
>>>>
>>>> Anyone who wants to do it has my support, though.
>>>>
>>>> Vr gr Peter Elderson
>>>>
>>>>
>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>> dieterdre...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> sent from a phone
>>>>>
>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>> >
>>>>> > Normal OSM access is assumed to be access=yes, where some access is
>>>>> restricted then in OSM it should be marked *=no.
>>>>>
>>>>>
>>>>> for roads access=yes is assumed, it is not necessarily the default for
>>>>> all kind of features.
>>>>>
>>>>>
>>>>> 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
>>
> ___
> 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] Network-tag needs extension

2020-08-24 Thread Peter Elderson
>
> how could you change the definition of an undocumented tag?
>

 Easy. It happens all the time, you just never hear about 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] Benches and hostile architecture

2020-08-24 Thread Peter Elderson
Wouln't it be more osm to describe visible and verifiable attributes of 
features, rather than architectural design principles or supposed intentions?

Mvg Peter Elderson

> Op 24 aug. 2020 om 12:11 heeft Florian Lohoff  het volgende 
> geschreven:
> 
> On Sun, Aug 23, 2020 at 01:22:38PM -0700, Joseph Eisenberg wrote:
>> The term "hostile architecture" is too vague. As an alternative
>> "anti-homeless" is also not precise enough. We are getting closer with the
>> initial suggestion that the feature is to prevent lying down, sleeping or
>> sitting.
> 
> Its not just anti-homeless there are also features which are explicitly 
> anti-skateboard etc
> 
> Flo
> -- 
> Florian Lohoff f...@zz.de
>UTF-8 Test: The  ran after a , but the  ran away
> ___
> 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] Benches and hostile architecture

2020-08-23 Thread Peter Elderson
The British really call bench construction "architecture"? Amazing. I can see 
this going the same way as village green.

Mvg Peter Elderson

> Op 23 aug. 2020 om 22:59 heeft Andy Townsend  het volgende 
> geschreven:
> 
> On 23/08/2020 21:22, Joseph Eisenberg wrote:
>> The term "hostile architecture" is too vague.
> 
> It is the normal British English (at least) description of this stuff.
> 
> 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] Canopy Walkways

2020-08-22 Thread Peter Elderson
I would say the feature is a kind of highway.
The construction is bridge, so bridge=yes on the highway.
The highway is a footway, and this kind of footway is called a canopy
walkway.

The footway part is kind of redundant, which is probably nice if you render
all footways, but unnecessary when you render canopy_walkways specifically.


Best Peter Elderson


Op za 22 aug. 2020 om 11:16 schreef Jake Edmonds via Tagging <
tagging@openstreetmap.org>:

> Should the key be bridge?
> I feel like canopy walkways are more like bridges than boardwalks.
>
> Sent from Jake Edmonds' iPhone
>
> On 22 Aug 2020, at 11:08, Alan Mackie  wrote:
>
> 
>
>
> On Fri, 21 Aug 2020, 21:46 Martin Koppenhoefer, 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 21. Aug 2020, at 22:25, Andy Mabbett 
>> wrote:
>> >
>> > "public building" and "trunk highway" are also common terms.
>> >
>> > Do we tag
>> >
>> >building=public_building
>> >
>> > or
>> >
>> >highway=trunk_hghway
>>
>>
>> these are different because it would be a literal repetition. What we do
>> is footway=sidewalk rather than „side“
>>
>> If general opinion is towards footway=canopy I could live with it, but my
>> preference goes to canopy_walkway
>> I’m not expecting so many that the extra characters will be significant
>> ;-)
>>
>
> I have had to remind myself several times as this thread has developed
> that this is not intended as a synonym for breezeway or other covered=yes
> footways.
>
> If the previously suggested =treetop isn't accurate perhaps a more
> explicit =forest_canopy ?
>
>
>> 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] Canopy Walkways

2020-08-21 Thread Peter Elderson
Do we tag 
 highway=motor ?

Mvg Peter Elderson

> Op 22 aug. 2020 om 00:37 heeft Andy Mabbett  het 
> volgende geschreven:
> 
> On Fri, 21 Aug 2020 at 21:44, Martin Koppenhoefer
>  wrote:
> 
>>>   highway=trunk_hghway
> 
>> these are different because it would be a literal repetition.
> 
> Do we tag:
> 
>   highway=trunk_road ?
> 
> -- 
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> 
> ___
> 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 - Voting - kerb=regular

2020-08-21 Thread Peter Elderson
Nederland: stoeprand (/stooprund/);  officially: trottoirband
(/trotwharbund/)
I wonder what it is in Burundi and Iceland.

Vr gr Peter Elderson


Op vr 21 aug. 2020 om 09:39 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 21. Aug 2020, at 03:34, 80hnhtv4agou--- via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > in the united states it is Curb.
>
>
> in Germany it is Bordstein
>
> 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] Canopy Walkways

2020-08-21 Thread Peter Elderson
footway on bridge construction, so highway=footway, bridge=yes seems ok.

Canopy walkway is the term I see used everywhere, not canopy bridge.

Makes sense to attach the canopy detail to the footway then. So
footway=canopy_walkway sounds right to me.


Best, Peter Elderson


Op vr 21 aug. 2020 om 08:46 schreef Volker Schmidt :

> The footway= approach isn't so good. A canopy walkway is more a bridge
> type.
>
> On Fri, 21 Aug 2020, 00:28 Graeme Fitzpatrick, 
> wrote:
>
>>
>>
>>
>> On Fri, 21 Aug 2020 at 07:50, Martin Koppenhoefer 
>> wrote:
>>
>>>
>>> Or maybe footway=canopy_walkway? highway= Footway and bridge=yes seem
>>> essential for a basic description.
>>>
>>
>> The combination of the three of them seems like a good, simple solution!
>>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-19 Thread Peter Elderson
Two dots are used in some circles to indicate inclusive range. eg 21..27.

Best, Peter Elderson


Op wo 19 aug. 2020 om 00:25 schreef Tod Fitch :

>
> On Aug 18, 2020, at 2:29 PM, Colin Smale  wrote:
>
>
> Maybe we should use a different character to indicate a range, such as a
> slash?
>
>
>
> In the United States it is not too uncommon for infill housing in urban
> areas to have fractional street numbers. So you can see addresses like “123
> 1/2 North Main Street” for a building located between 123 and 125 (odd
> numbers are usually on one side of the street so 124 is not available in
> this example). I already am annoyed by QA checkers that flag that as an
> error. Defining a slash to mean something other that the, to me, obvious
> use as a fraction would make things worse.
>
> Cheers,
>
> Tod
>
>
> ___
> 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] new page for tree_lined=*

2020-08-15 Thread Peter Elderson
Martin Koppenhoefer:

> I think we can assume that a line of trees in the middle is sufficient to
> make mappers use 2 highways instead of 1!? How can we distinguish between
> the following sections
> tree - road - tree - road - tree
> and
> tree - road - tree - tree - road - tree
> and
> tree - road - tree - significant “void“ space - tree - road - tree?
>

I would not make too much of it. The attribute gives the aspect of the
road, not the actual feature with details. So, all cases: both roads look
tree lined at both sides, so they get tree_lined=both.

If the space is significant, better map it as a landuse feature. Sometimes
a complete wildlife reserve can be found between road halves.

Example:  trees - road - trees - cycleway : the road gets tree_lined=both
and the cycleway tree_lined=left (assuming forward direction of the way and
righthand driving).

___
> 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] new page for tree_lined=*

2020-08-15 Thread Peter Elderson
Nederland has an awful lot of ways, waterways, railways, rivers, parkings,
churchyards, and other linear and area features which are lined with a row
of trees. And if I say a row of trees, think of 10 Km almost straight with
a continuous line of evenly spaced trees at both sides, sometimes also in
the middle, sometimes double or triple rows at each side, often with a
separately lined cycleway and tree_lined ditches.

Even in the woods, roads often have a separate distinct tree lining, often
between the road and the cycleways on both sides.

As it is a distinctive and verifiable (by survey, by viewers and by
satellite imagery) attribute of the road, it is worth mapping as
secondary tag. The purpose varies and can be guessed but seldom verified,
so best not try to define by purpose, just map what you see. Unlike
cycleways and sidepaths along roads, no routing has to be done over a line
of trees, but the attribute is nice to know for cyclists, hikers and
motorists.

One thing: we have tree rows in the middle of a road, not always combined
with a side tree row.
Maybe map that as a tree_row feature?

About generic: I wouldn't call tree_lined a generic attribute. It
specifically says the feature is lined by trees. Generic tagging IMO would
be: lined=* where the value specifies which lining is used.
If you want further specification of the tree_line details, I would suggest
to use natural=tree_row and tag everything you wish to record about the
trees.

I don't really care if it's on a separate tree_line page.

Best, Peter Elderson


Op vr 14 aug. 2020 om 01:08 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> I’ve set up an initial documentation page for the tree_lined attribute
> (used mainly in conjunction with highways and waterways) and welcome
> comments for it:
>
> https://wiki.openstreetmap.org/wiki/Key:tree_lined
>
>
> This used to be a redirect to natural=tree_row (which is a different tag,
> as it is for a feature, not an attribute).
> There are also already translations in
> cs, de, es and uk (also redirects), which should be updated.
>
> Cheers Martin
>
>
> sent from a phone
> ___
> 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] new page for tree_lined=*

2020-08-13 Thread Peter Elderson
I can see how an area such as a parking, a churchyard or pedestrian area
can be tree lined. A node feature, not so much.

Best, Peter Elderson


Op vr 14 aug. 2020 om 01:08 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> I’ve set up an initial documentation page for the tree_lined attribute
> (used mainly in conjunction with highways and waterways) and welcome
> comments for it:
>
> https://wiki.openstreetmap.org/wiki/Key:tree_lined
>
>
> This used to be a redirect to natural=tree_row (which is a different tag,
> as it is for a feature, not an attribute).
> There are also already translations in
> cs, de, es and uk (also redirects), which should be updated.
>
> Cheers Martin
>
>
> sent from a phone
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-25 Thread Peter Elderson


Mvg Peter Elderson

> Op 25 jul. 2020 om 22:43 heeft Allroads  het 
> volgende geschreven:
> 
> The earlier mentioned,
> bicycle=leave
> This is for me, leave the bicycle behind at the sign.
> More native English speakers can give a comment on that?

If you're not with bike, the sign/access doesn't apply. If you are with bike, 
you will have to leave it there before passing the sign. if you are planning/ 
routing, the software will warn that you will have to leave the bike there if 
you want to pass. 

Looks useless, but in fact a lot of places have a no bike perimeter, usually 
with bicycle parking of sorts.

Works with anything you can carry, push or lead. 

>  ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-25 Thread Peter Elderson
Op 25 jul. 2020 om 22:43 heeft Allroads  het volgende 
geschreven:
> So, now we need also a hard yes. That you must bring a bicycle with you.

That's an attribute of the bus service/transfer, not the road, I think.

>  
> ___
> 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 "guideposts" painted on rocks, trees etc.

2020-07-25 Thread Peter Elderson
Op za 25 jul. 2020 om 13:07 schreef Andy Townsend :

>
> (re adding guideposts to route relations)
>
> On 21/07/2020 22:18, Peter Elderson wrote:
> > I think the Why question comes first.

Why do people in OSM map anything?  I can't see any reason why I'd want
> to add urban buildings, or comprehensive address data, or a whole bunch
> of other things that people think are _really important_.


That's why I ask.


> To answer the direct question - having the guideposts visible as part of
> the relation makes it easy to visualise how (and where) a trail is signed.
>

(I don't disagree, just playing DA).
1. Unsigned trails should not be in the map database (yes I know, with a
few very noteable exceptions eg a crest trail known by everybody but me, it
follows the crest so you could say, the crest is the signage).

2. The guideposts are on or near the trail, so the association is there.
They are visible on the map on or near the trail as features of their own.

3. Symbol, colour, ref, name, operator on guideposts and other waymarks,
are tagged on the route relation. That's what makes it a route, not the
exact position of the waymarks and guideposts. The waymarks could all be
repositioned while the route stays the same. In fact,  I maintain a route
that coïncides with another one for a stretch. The positions of guideposts
and other waymarks is very very different, still the routes on that stretch
are identical.

I think the why (why does it need to be *in the relation) *needs more than
this. I don't oppose, but I see a lot of maintenance work; which is fine if
there is a purpose in terms of data use and rendering, and a
probablity that people will use the information for real.




> https://www.openstreetmap.org/relation/1996318 is "officially unmarked",
> but there is some signage - more in some places than others.
>
> https://www.openstreetmap.org/relation/8450999 I've walked quite a lot
> of and I've found exactly _one_ guidepost so far.
>
> https://www.openstreetmap.org/relation/6366232#map=11/54.4646/-0.9798 I
> have not found any signage for at all.
>
> 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] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Peter Elderson
Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr :

> On 24.07.20 14:13, Peter Elderson wrote:
> > In comparable cases (non-OSM, but comparible checking schemes), I do not
> > record the date it has been checked, I record the future date when it
> > should be checked (again).
>
> When it should be checked is opinion-based, though.
>

True, and the opinion is the user's opinion at the time of the survey. You
can suggest a default re-check date for the type of feature (might also be
empty) and leave it up to the user to accept or change that.



> The date when you last checked a shop's opening hours it is a fact. But
> opinions on how often one should revisit a shop to check the opening
> hours again may vary a lot between mappers. So I think the former is
> more suitable to be added to the OSM database.
>

It's a historic fact, but it doesn't drive any plan.


> There are some comparatively rare cases where you know in advance that
> something will change (e.g. with construction that is scheduled to be
> finished by a particular date), but imo that's more the domain of
> opening_date or temporary tags.
>
> > The routine is then, ask if check_date is absent OR when the current
> > date is past the check_date.
>
> I don't think this is a big benefit compared to "... OR when the current
> date is X months past the check_date".
>

I think you are thinking code in the app, not maintaining a bunch of
features such as 35000 routes or all the Stolpersteine in the area

The difference is the determination of X. It's feature and
opinion-dependent. Checking/displaying due checks is very simple, and
doesn't have to know anything, just compare the tag with the date, and all
pop up.


> Also, I tend to prefer making software a little more complicated if it
> lightens mappers' manual workload, so making at least some use of
> history (e.g. so that no check_date needs to be set when a tag is first
> added) seems reasonable to me.
>

As a maintaining mapper, I would set the future check_date at entry time.

Your plan sounds fine, but it will not be of much use to me. I still have
to maintain an agenda and listst for checks in the future. If a
future check mechanism were in place, I'd simply display a check map, just
like a map showing all notes or all fixme's.

>
> ___
> 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] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Peter Elderson
Firstly, I think this kind of application is very important for the
maintenance of the map. The thing has become too complicated for regular
people. So, kudo's!

Secondly, I think having to evaluate the history is a challenge. But do you
have to?
In comparable cases (non-OSM, but comparible checking schemes), I do not
record the date it has been checked, I record the future date when it
should be checked (again).

The routine is then, ask if check_date is absent OR when the current date
is past the check_date.

You can vary check_date according to the feature. You could ask the user to
confirm the suggested future check_date or enter a better one.

Easy overpass queries can find objects past the check_date. Easy maps can
show objects past the check_date. It's all much simpler than searching
possibly complex history.

Vr gr Peter Elderson


Op do 23 jul. 2020 om 18:08 schreef Tobias Zwick :

> Hello everyone
>
> As you may or may not know, my microgrant proposal "Map maintenance with
> StreetComplete" [1] was selected to be funded by the OSMF. So, I am
> happy to have the oppurtunity to invest the time  extending the app,
> hoping that it will help to keep the map up-to-date and unburden people
> and communities invested in that topic.
>
> I am pitching this here because there are three details on which I would
> like to hear your input. Two of these are about tagging.
>
> But first, how will it work?
> 
>
> So, what StreetComplete will do is to scan the map for whether certain
> properties (tags) of map features haven't been surveyed for a certain
> time. If this is the case, users will be prompted to answer the question
> for that property again. For example, if the app ascertained that the
> smoothness of a road hasn't been changed for 5 years, it would ask users
> again about the smoothness of the road.
>
> Challenges
> --
>
> Now, you might imagine that this is not so straightforward to implement,
> and you would be right, for several reasons:
>
> Firstly, the OSM API has no notion about when a particular property of
> an element has last been changed, only for when the whole element has
> last been changed. But elements are changed all the time for various
> reasons. Roads for example tend to be changed especially often, splitted
> up to accomodate bus routes, turn restrictions, when detailing
> intersections, etc.
>
> Secondly, there is only the date of the last change, but that doesn't
> mean that is the date of the last survey. Even though that would be the
> information we are interested in: when has the element last been checked
> on-site?
>
> Thirdly, the OSM API does not offer users to record solely that they
> checked something and that it is still up to date. Any new record in OSM
> must always come with a tagging change.
>
> Solutions
> -
>
> In the absence of direct API support, fortunately the community came up
> with a solution: Add the check_date tag to the element that has been
> checked on a survey - or with the namespace if it concerns only a
> certain tag of a map feature.
>
> This works well and is actually already used by Streetcomplete in the
> "Is this construction site finished?"-quest:
> If the element as a whole hasn't been changed for 6 months *or* the
> check_date key is present and its value is older than 6 months, the
> quest is eligible to be asked again. When the user answers the question,
> the check_date is set to current date.
>
> Your input
> ==
>
> Now here is where I would like your input:
>
> 1. Use check_date:smoothness or smoothness:check_date?
> --
> check_date with a namespace isn't used all that often yet, both variants
> are used and thus there is no real winner yet. What variant do you
> prefer and why? And most importantly, which variant would be most
> consistent with existing tagging practices?
>
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?
>
> ---
> If something is resurveyed and it is acknowledged that nothing changed,
> it is absolutely necessary to tag check_date. If something changed, it
> is not strictly necessary because that the element changed as a whole is
> itself also recorded.
> But as already mentioned, elements can and do change all the time. One
> can not assume that if an element has been changed that it has been
> checked on-site. And even if one could, maybe not all the things were
> checked but for example only the bus route relation, or maybe only the
> presence of a sidewalk, or someone made the way a little more detailed etc.
>
> The topic whe

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Peter Elderson
bicycle=leave

Vr gr Peter Elderson


Op do 23 jul. 2020 om 23:32 schreef Mike Thompson :

>
>
> On Thu, Jul 23, 2020 at 2:34 PM Matthew Woehlke 
> wrote:
> >
>
> >
> > ...but then your horse is a passenger in a vehicle. Otherwise that would
> > be like saying a human can't ride in a vehicle if foot=no.
> Exactly, foot=no doesn't mean that feet are not allowed, it means that
> using a mode of transportation that primarily uses feet  ("foot
> travel"/walking/running/hiking) isn't allowed.
> bicycle=no is consistent with this, it doesn't mean that bicycles are
> prohibited, it means that a mode of transportation, (bicycle riding) is
> prohibited.
> horse=no is apparently a  little different as you point out.  It seems to
> refer not just to a mode of transportation, but to the possession of the
> animal in general.  It is similar to dog=no. dog=no doesn't refer to
> whether you can use a dog as a mode of transportation, it means you can't
> possess a dog at all on the given way (even if you carry it).
>
>
> >
> > For similar reasons, I would assume that a way that allows vehicles but
> > not pushed bicycles allows a bicycle *in* a vehicle.
> Right, because it is no longer the mode of transportation.
>
> > FWIW, I'm sympathetic to the "no means no" camp and just declaring that
> > if you really meant "dismount", *fix it*.
> well, "no does mean no", it means "no bicycle riding", it means, no using
> a bicycle as a mode of transportation. It doesn't say anything about
> possessing a bicycle in general, or using it in another manner (pushing,
> carrying)
> "dismount" is not the complete solution, because, as the original question
> implied, sometimes it is also illegal to carry a bicycle (although I have
> never seen that), and as someone else pointed out, sometimes it is illegal
> to even possess a bicycle at all, such as in a US Wilderness Area.
>
> Mike
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Peter Elderson
bicycle=leave
Vr gr Peter Elderson


Op wo 22 jul. 2020 om 17:36 schreef Tod Fitch :

>
>
> On Jul 22, 2020, at 8:09 AM, Jmapb  wrote:
>
> If this unfortunate tagging practice really needs to be preserved (the
> idea of retagging so many bicycle=no ways is certainly daunting) then I'd
> suggest a new key, dismounted_bicycle=*, which will function as a
> regulation key (like smoking=*) rather than a vehicle access key. Total
> bicycle prohibition would be encoded with both bicycle=no and
> dismounted_bicycle=no, and other dismounted_bicycle=* values can be
> developed for whatever the regulations are in particular situations.
>
> Why? The suggestion that all the places that properly tagged bicycles=no
> now need to be revisited and have a new dismounted_bicycles=no tag added
> implies that the people who took “no” to mean something other than “no”
> prevail and the rest of us have to go back and re-tag things.
>
> Since many miles/kilometers of ways will need to be retagged either way,
> why not go with the straight forward “no means no” and “dismount means
> dismount”? Makes a lot more sense to me that “no only really means no if
> there is an additional dismounted_bicycle=no” tag too.
>
> Cheers!
>
> —Tod
>
>
>
> ___
> 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 "guideposts" painted on rocks, trees etc.

2020-07-21 Thread Peter Elderson
I think the Why question comes first!

Best, Peter Elderson


Op di 21 jul. 2020 om 21:47 schreef Andy Townsend :

> On 21/07/2020 20:37, pangoSE wrote:
> >
> > Andy Townsend  skrev: (21 juli 2020 13:31:45 CEST)
> >
> >> I've also been trying to add these (both guideposts and route markers)
> >> to the relevant hiking route relation.
> > That does not sound right to me. Why would you do that?
>
> How would you indicate which relation a particular guidepost or route
> marker belongs to?
>
> 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] site relations for city walls?

2020-07-14 Thread Peter Elderson
Sure! I was just sidestepping about the parking lot example.

Best, Peter Elderson


Op di 14 jul. 2020 om 18:34 schreef Volker Schmidt :

> Sorry to keep riding this horse, but many of my examples have areas, ways
> and nodes as members, so they cannot be described by any kind of polygon.
> Lets take my favourite example of a dismantled railway.
> It contains:
>
>- nodes: tourist information tables
>- ways: embankments, all kinds of highways
>- areas: former railway buildings, bridge structures, vegetation areas
>(that correspond to the former rail bed)
>
>
>
>
> On Tue, 14 Jul 2020 at 18:17, Peter Elderson  wrote:
>
>> https://wiki.openstreetmap.org/wiki/Multipolygon_Examples  example 1.7
>> describes disjunct outers.
>>
>> Too bad you have to wrestle through some very complicated examples to get
>> there if you start at the beginning. And, these complex examples should not
>> be followed, because they advocate tying landuse to ways, borders to ways
>> and other stuff you really should not do if you want to keep the map
>> unbroken.
>>
>> Best, Peter Elderson
>>
>>
>> Op di 14 jul. 2020 om 18:05 schreef Peter Elderson :
>>
>>> Just two outers is a regular use of multipolygon.
>>> If the tags of two areas are the same, you can represent two or more
>>> distinct areas as a multipolygon
>>>
>>> If you have one area as a multipolygon with an inner, a separate closed
>>> way can be used as an extra outer, it will then get the attributes of the
>>> multipolygon.
>>>
>>> Major renderers support this.
>>>
>>> One parking lot on two sides of a road is perfect for this method.
>>>
>>> Best, Peter Elderson
>>>
>>>
>>> Op di 14 jul. 2020 om 16:55 schreef Lionel Giard >> >:
>>>
>>>> Wouldn't a multipolygon with just two outers solve that parking case?
>>>>> Best Peter Elderson
>>>>>
>>>>
>>>> That's a bit of a stretch of the multipolygon definition as there is no
>>>> inner ring.  I never used multipolygon for anything else than complex
>>>> geometry (with inner ring(s)) and that seems to be what the feature is for.
>>>>
>>>> As we already have the site relation for grouping features that are
>>>> part of the same thing, but disjoint, i think that it is good to use it. It
>>>> also solves the problem when mappers use multipolygon for two polygons
>>>> sharing the same edge (it is forming an invalid geometry), while with site
>>>> relation it is not a problem. Another advantage is that it is quite easy to
>>>> edit. You just need to add or remove a feature : no specific roles (yet) or
>>>> order needed.
>>>>
>>>> Le lun. 13 juil. 2020 à 23:29, Volker Schmidt  a
>>>> écrit :
>>>>
>>>>>
>>>>>
>>>>> On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer <
>>>>> dieterdre...@gmail.com> wrote:
>>>>>
>>>>>> actually all of these could be „grouped“ with tags alone, e.g
>>>>>> distributed museums could have an identifying „network“ tag (or sth
>>>>>> similar).
>>>>>>
>>>>> But why invent a new network tag, if we have  a site relation, waiting
>>>>> to be used. (I was thinking of open air museums, where the various 
>>>>> exhibits
>>>>> are spread over the landscape)
>>>>>
>>>>>> For power plants a site might be appropriate, if an area does not do
>>>>>> it and you don’t want to rely on only tags.
>>>>>>
>>>>> If you have ever looked at the complexities of a hydro-power-plant
>>>>> with dams, lakes, pipes, turbines deep in the mountains or in dedicated
>>>>> buildings . they are really complex, and only parts of it are visible on
>>>>> the surface.
>>>>>
>>>>>> In theory objects like the Great Wall in China can and should be
>>>>>> modeled as areas, although they seem to be linear in nature, they are 
>>>>>> also
>>>>>> thick enough to „require“ an area representation in order to be well 
>>>>>> mapped
>>>>>> in the scale of OpenStreetMap (you can walk on it).
>>>>>>
>>>>> That's not true - you can walk on parts of it, other parts are
>>>>> completely missing, oth

Re: [Tagging] site relations for city walls?

2020-07-14 Thread Peter Elderson
https://wiki.openstreetmap.org/wiki/Multipolygon_Examples  example 1.7
describes disjunct outers.

Too bad you have to wrestle through some very complicated examples to get
there if you start at the beginning. And, these complex examples should not
be followed, because they advocate tying landuse to ways, borders to ways
and other stuff you really should not do if you want to keep the map
unbroken.

Best, Peter Elderson


Op di 14 jul. 2020 om 18:05 schreef Peter Elderson :

> Just two outers is a regular use of multipolygon.
> If the tags of two areas are the same, you can represent two or more
> distinct areas as a multipolygon
>
> If you have one area as a multipolygon with an inner, a separate closed
> way can be used as an extra outer, it will then get the attributes of the
> multipolygon.
>
> Major renderers support this.
>
> One parking lot on two sides of a road is perfect for this method.
>
> Best, Peter Elderson
>
>
> Op di 14 jul. 2020 om 16:55 schreef Lionel Giard :
>
>> Wouldn't a multipolygon with just two outers solve that parking case?
>>> Best Peter Elderson
>>>
>>
>> That's a bit of a stretch of the multipolygon definition as there is no
>> inner ring.  I never used multipolygon for anything else than complex
>> geometry (with inner ring(s)) and that seems to be what the feature is for.
>>
>> As we already have the site relation for grouping features that are part
>> of the same thing, but disjoint, i think that it is good to use it. It also
>> solves the problem when mappers use multipolygon for two polygons sharing
>> the same edge (it is forming an invalid geometry), while with site relation
>> it is not a problem. Another advantage is that it is quite easy to edit.
>> You just need to add or remove a feature : no specific roles (yet) or order
>> needed.
>>
>> Le lun. 13 juil. 2020 à 23:29, Volker Schmidt  a
>> écrit :
>>
>>>
>>>
>>> On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer <
>>> dieterdre...@gmail.com> wrote:
>>>
>>>> actually all of these could be „grouped“ with tags alone, e.g
>>>> distributed museums could have an identifying „network“ tag (or sth
>>>> similar).
>>>>
>>> But why invent a new network tag, if we have  a site relation, waiting
>>> to be used. (I was thinking of open air museums, where the various exhibits
>>> are spread over the landscape)
>>>
>>>> For power plants a site might be appropriate, if an area does not do it
>>>> and you don’t want to rely on only tags.
>>>>
>>> If you have ever looked at the complexities of a hydro-power-plant with
>>> dams, lakes, pipes, turbines deep in the mountains or in dedicated
>>> buildings . they are really complex, and only parts of it are visible on
>>> the surface.
>>>
>>>> In theory objects like the Great Wall in China can and should be
>>>> modeled as areas, although they seem to be linear in nature, they are also
>>>> thick enough to „require“ an area representation in order to be well mapped
>>>> in the scale of OpenStreetMap (you can walk on it).
>>>>
>>> That's not true - you can walk on parts of it, other parts are
>>> completely missing, others are heaps of stones.
>>>
>>>> In practice we would also want a way to have preliminary mapping as a
>>>> line, and mixed geometry relations. A multipolygon relation for all parts
>>>> of the great wall would likely be broken every day, and would be over the
>>>> member limits for relations.
>>>>
>>> It's not a multipolygon - it is bits and pieces, some connected, same
>>> not. Some may be linear (in first approximation).
>>>
>>>
>>>> Would those that are in favour of using a site relation for a linear,
>>>> circular, interrupted structure, 19km long and some meters wide, also see
>>>> it as a good relation type for the Chinese Great Wall?
>>>>
>>> You lost me with your question here.
>>>
>>> Volker
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>  Virus-free.
>>> www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>> <#m_7578338272934009314_m_-2578868543391359494_m_8037950653339377666_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> ___
>>> 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] site relations for city walls?

2020-07-14 Thread Peter Elderson
Just two outers is a regular use of multipolygon.
If the tags of two areas are the same, you can represent two or more
distinct areas as a multipolygon

If you have one area as a multipolygon with an inner, a separate closed way
can be used as an extra outer, it will then get the attributes of the
multipolygon.

Major renderers support this.

One parking lot on two sides of a road is perfect for this method.

Best, Peter Elderson


Op di 14 jul. 2020 om 16:55 schreef Lionel Giard :

> Wouldn't a multipolygon with just two outers solve that parking case?
>> Best Peter Elderson
>>
>
> That's a bit of a stretch of the multipolygon definition as there is no
> inner ring.  I never used multipolygon for anything else than complex
> geometry (with inner ring(s)) and that seems to be what the feature is for.
>
> As we already have the site relation for grouping features that are part
> of the same thing, but disjoint, i think that it is good to use it. It also
> solves the problem when mappers use multipolygon for two polygons sharing
> the same edge (it is forming an invalid geometry), while with site relation
> it is not a problem. Another advantage is that it is quite easy to edit.
> You just need to add or remove a feature : no specific roles (yet) or order
> needed.
>
> Le lun. 13 juil. 2020 à 23:29, Volker Schmidt  a
> écrit :
>
>>
>>
>> On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer 
>> wrote:
>>
>>> actually all of these could be „grouped“ with tags alone, e.g
>>> distributed museums could have an identifying „network“ tag (or sth
>>> similar).
>>>
>> But why invent a new network tag, if we have  a site relation, waiting to
>> be used. (I was thinking of open air museums, where the various exhibits
>> are spread over the landscape)
>>
>>> For power plants a site might be appropriate, if an area does not do it
>>> and you don’t want to rely on only tags.
>>>
>> If you have ever looked at the complexities of a hydro-power-plant with
>> dams, lakes, pipes, turbines deep in the mountains or in dedicated
>> buildings . they are really complex, and only parts of it are visible on
>> the surface.
>>
>>> In theory objects like the Great Wall in China can and should be modeled
>>> as areas, although they seem to be linear in nature, they are also thick
>>> enough to „require“ an area representation in order to be well mapped in
>>> the scale of OpenStreetMap (you can walk on it).
>>>
>> That's not true - you can walk on parts of it, other parts are completely
>> missing, others are heaps of stones.
>>
>>> In practice we would also want a way to have preliminary mapping as a
>>> line, and mixed geometry relations. A multipolygon relation for all parts
>>> of the great wall would likely be broken every day, and would be over the
>>> member limits for relations.
>>>
>> It's not a multipolygon - it is bits and pieces, some connected, same
>> not. Some may be linear (in first approximation).
>>
>>
>>> Would those that are in favour of using a site relation for a linear,
>>> circular, interrupted structure, 19km long and some meters wide, also see
>>> it as a good relation type for the Chinese Great Wall?
>>>
>> You lost me with your question here.
>>
>> Volker
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> <#m_-2578868543391359494_m_8037950653339377666_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> 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 - (Ground)

2020-07-13 Thread Peter Elderson
That's OSM in a nutshell.

Mvg Peter Elderson

> Op 13 jul. 2020 om 23:24 heeft Martin Koppenhoefer  
> het volgende geschreven:
> 
> 
> 
> sent from a phone
> 
>> On 13. Jul 2020, at 23:16, Peter Elderson  wrote:
>> 
>> As I understand it, it is soil. That is something.
> 
> 
> sure, you could also spend a lifetime mapping rocks, and when you’re done, 
> you start mapping smaller rocks ;)
> 
> 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 - (Ground)

2020-07-13 Thread Peter Elderson
As I understand it, it is soil. That is something.

Vr gr Peter Elderson


Op ma 13 jul. 2020 om 23:09 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 13. Jul 2020, at 22:36, Joseph Eisenberg 
> wrote:
> >
> > The Atacama desert has many areas of bare sand and rock, but also some
> places with mixed stoney soil:
>
>
> how would you map this? Are we going to map the voids? Usually in an area
> like this I would expect that a map, especially one that is made from the
> people on the ground, has the features, not the un-features.
> Maybe it’s just me, but it doesn’t sound terribly exciting to map huge
> areas of un-landcover, to then cut everything out that is something, when
> you could just map the something and be done.
>
> 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] site relations for city walls?

2020-07-13 Thread Peter Elderson
Wouldn't a multipolygon with just two outers solve that parking case?
Best Peter Elderson


Op ma 13 jul. 2020 om 21:02 schreef Lionel Giard :

> I also saw it used for parking lot that are completely separated (like on
> two sides of a big highway) but still part of the "same" parking
> technically (like the example of mall parking in different parts separated
> by highways). To add to the two area mapped as amenity=parking, there was a
> site relation grouping them (site=parking).  ^_^
>
> Le lun. 13 juil. 2020 à 19:04, Volker Schmidt  a
> écrit :
>
>> Looking back at the history of the site relation, it looks as if the
>> concept originated from schools, colleges, universities, airports,  and
>> military bases for situations where the objects are not within a well
>> defined perimeter. Documented uses include historical sites, even though
>> they are not quoted in recent versions of the wiki page.
>>
>> Reading the wiki versions, I would say the "site" relation is extremely
>> vaguely defined.
>>
>> I would think we are free to make it something useful.
>>
>> At the risk of repeating myself, I believe there is a need  for something
>> like the site relation for a whole array of more or less widely scattered
>> objects that belong together. Just a few:
>>
>>- non-campus universities, research institutions, schools
>>- the offices of public institutions (city, regional, country
>>governments, the European Union institutions)
>>- archaeological sites (aqueducts, Hadrian's Wall, the Limes in
>>Germany, the Great Wall of China, The Iron Curtain, city walls, former
>>Railways, former canals and other waterways, former underground mines, 
>> ...)
>>- power plants (hydro-electric, wind power, ...)
>>- active mines
>>- distributed museums
>>
>> Volker
>>
>>
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> <#m_-1596189521018685984_m_-7074691897933095803_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> 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] network tag on route relations

2020-07-13 Thread Peter Elderson
Route=foot, route=hiking, route=bicycle, route=piste, route=inline_skates,
route=canoe, route=horse.

modality may be a wrong word? It's used in Nederland to mean transport
mode, including walking.

Vr gr Peter Elderson


Op ma 13 jul. 2020 om 20:29 schreef Paul Johnson :

> What is a recreational route and how's it got anything to do with talking
> about modality?
>
> On Mon, Jul 13, 2020 at 1:25 PM Peter Elderson 
> wrote:
>
>> Nederland, Germany and Belgium also have walking routes, horse routes,
>> inline-skating routes, canoe routes, motorboat routes. Also a myriad of
>> node networks for all the modalities, some completely developed and
>> covering the country (cycling node networks), some almost nation-wide but
>> locally or regionally maintained (walking node networks), some in the early
>> stages but spreading rapidly, also to other countries (Austria, France,
>> Spain).
>> The lXn, rXn, nXn, iXn system, combined with network:type=node_network,
>> operator, and ref, , covers all recreational routes, in many countries with
>> very different systems of administration and maintenance.
>>
>> If there is a conflict between the use of those routes and the highway
>> road routes coding system, that would be a problem requiring a solution.
>> Perceived inconsistency  between clearly different uses of the route
>> relation iis not.
>>
>> I think this recreational route network coding has earned its place.
>> Still, if an actual problem arises, I would be happy to help solve it. I
>> know some people think the network=XXn system is principally flawed and
>> should never have been approved, but I have yet to see one actual problem
>> and it appears to do the job around the world, for recreational routes of
>> all scopes and modalities, even though countries have very different
>> administration and maintenance systems from completely central to
>> distributed and chaotic, and different for most modalities.
>>
>> Best, Peter Elderson
>>
>>
>> Op ma 13 jul. 2020 om 18:51 schreef Volker Schmidt :
>>
>>>
>>>
>>>
>>> I am not saying get rid of the network tag, I am saying we should be
>>>> consistent.  In the above case, if  network=UK (instead of network=ncn),
>>>> one would know it is national. First because the UK is a nation and there
>>>> is no smaller jurisdiction that follows "UK" in the tag, and because there
>>>> would be cycle routes all over the UK where network=UK.
>>>>
>>>
>>>
>>> Numbering in the UK reflects the "importance" of a route:
>>> National routes carry two-digit numbers
>>> Regional routes carry three-digit numbers
>>> Local cycle routes are less consistently labelled.
>>> OSM, born in the UK  has inherited this approach
>>>
>>> The UK national bicycle network is managed by Sustrans - see
>>> https://www.sustrans.org.uk/national-cycle-network
>>>
>>> Similarly tiered systems exist in the Netherlands and Germany.
>>>
>>> In Italy there is a similar approach, that mirrors the administrative
>>> organisation of the country: National routes connect several regions.
>>> Regional routes connect severela provinces and local routes are typically
>>> within a single province.
>>>
>>> Volker (Italy)
>>>
>>>
>>>
>>>
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>  Virus-free.
>>> www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>> <#m_-8739785874600031477_m_-2347637413674922412_m_-5475564013638110848_m_3447769538172802524_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> ___
>>> 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] network tag on route relations

2020-07-13 Thread Peter Elderson
Nederland, Germany and Belgium also have walking routes, horse routes,
inline-skating routes, canoe routes, motorboat routes. Also a myriad of
node networks for all the modalities, some completely developed and
covering the country (cycling node networks), some almost nation-wide but
locally or regionally maintained (walking node networks), some in the early
stages but spreading rapidly, also to other countries (Austria, France,
Spain).
The lXn, rXn, nXn, iXn system, combined with network:type=node_network,
operator, and ref, , covers all recreational routes, in many countries with
very different systems of administration and maintenance.

If there is a conflict between the use of those routes and the highway road
routes coding system, that would be a problem requiring a solution.
Perceived inconsistency  between clearly different uses of the route
relation iis not.

I think this recreational route network coding has earned its place. Still,
if an actual problem arises, I would be happy to help solve it. I know some
people think the network=XXn system is principally flawed and should never
have been approved, but I have yet to see one actual problem and it appears
to do the job around the world, for recreational routes of all scopes and
modalities, even though countries have very different administration and
maintenance systems from completely central to distributed and chaotic, and
different for most modalities.

Best, Peter Elderson


Op ma 13 jul. 2020 om 18:51 schreef Volker Schmidt :

>
>
>
> I am not saying get rid of the network tag, I am saying we should be
>> consistent.  In the above case, if  network=UK (instead of network=ncn),
>> one would know it is national. First because the UK is a nation and there
>> is no smaller jurisdiction that follows "UK" in the tag, and because there
>> would be cycle routes all over the UK where network=UK.
>>
>
>
> Numbering in the UK reflects the "importance" of a route:
> National routes carry two-digit numbers
> Regional routes carry three-digit numbers
> Local cycle routes are less consistently labelled.
> OSM, born in the UK  has inherited this approach
>
> The UK national bicycle network is managed by Sustrans - see
> https://www.sustrans.org.uk/national-cycle-network
>
> Similarly tiered systems exist in the Netherlands and Germany.
>
> In Italy there is a similar approach, that mirrors the administrative
> organisation of the country: National routes connect several regions.
> Regional routes connect severela provinces and local routes are typically
> within a single province.
>
> Volker (Italy)
>
>
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_-5475564013638110848_m_3447769538172802524_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] network tag on route relations

2020-07-13 Thread Peter Elderson
I can't see how that applies to recreational route networks in Europe. 

Mvg Peter Elderson

> Op 13 jul. 2020 om 15:33 heeft Paul Johnson  het 
> volgende geschreven:
> 
> 
> 
> 
>> On Mon, Jul 13, 2020 at 1:04 AM Peter Elderson  wrote:
>> Sounds to me that the scheme is creating a problem rather than solving it... 
>> requiring a lot of prior knowledge and tables to code, and expert knowledge 
>> and tables to decode. 
> 
> It's the same scheme already used for highways. 
> ___
> 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] network tag on route relations

2020-07-13 Thread Peter Elderson
Hi,
You might want to have a look at routes in Europe:
https://hiking.waymarkedtrails.org/#?map=5!47.0008!12.6323

Zoom and pan a little to get a feel for the extent of the route networks in
Europa and how they relate to countries. Bicycle networks (second tab) are
also very dense.

By contrast, the similar view of the US:
https://hiking.waymarkedtrails.org/#?map=5!40.3725!-99.2156

This is shown thanks to the consistent network tagging. I feel that trying
to implement a scheme meant for hierarchical road networks within a
country, would maybe work in the US, but in Europe it would do more damage
than good, even if it were possible.

Just "consistency" is not worth it. Is there a more compellent reason?

Vr gr Peter Elderson


Op zo 12 jul. 2020 om 16:49 schreef Mike Thompson :

> Hello,
>
> According to the wiki[0], it seems that the network tag has different
> meanings and possible values based upon if it is applied to a route
> relation where route=road vs. route=bicycle/mtb/foot/etc.
>
> If I am understanding this correctly, when route=road, network= the
> specific network that the road is part of, for example, a US Interstate
> would be US:I[2]
>
> For bicycle/mtb/foot etc. it seems that the network tag indicates the
> scope of the network, for example a nationwide network cycling network
> would network=ncn[1]
>
> 1) Why can't the network tag have consistent meaning across all route
> types? For a mapper, as well as a data user, this is confusing.
> 2) The scope of a cycling/walking/etc. network should be evident from the
> geographic extent of its members, so isn't network=icn/ncn/etc. redundant?
> In any event, if the specific network is specified, it will, in most cases,
> also indicate the general scope.
>
> Mike
>
> [0] https://wiki.openstreetmap.org/wiki/Key:network
> [1]
> https://wiki.openstreetmap.org/wiki/Key:network#Bicycle.2C_hiking_and_other_recreational_routes
> [2]https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
> ___
> 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] network tag on route relations

2020-07-13 Thread Peter Elderson
Sounds to me that the scheme is creating a problem rather than solving
it... requiring a lot of prior knowledge and tables to code, and expert
knowledge and tables to decode. If anything, I would want to make it
simpler, not more complicated.
Anyone who wants more consistency, please map all Dutch recreational routes
onto the new consistent scheme without breaking current rendering and
processing, if you can do it, let's talk again!

Mvg Peter Elderson

Op 13 jul. 2020 om 00:18 heeft Paul Johnson  het
volgende geschreven:


Disambiguation.  US:FS:Hood and US:FS:Ozark are two different national
forest service networks with entirely different numbering schemes.  Plus
network=CA by itself would be Canada, not California, which is US:CA...

On Sun, Jul 12, 2020 at 5:07 PM Peter Elderson  wrote:

> Well, recreational routes and networks simply are not that organized, and
> jurisdiction or authority doesn't apply to most of them. I guess that is
> why the values are more generic.
>
> I still don't understand why you tag "US" while it's obviously a bunch of
> roads in the US. or Interstate when the road clearly crosses state lines. I
> think that"s more redundant than tagging "we classify this route as a
> regional route", even though it might cross two national borders in a few
> places and half the roads are outside our borders, and we don't know the
> current operator or provider.
>
> Peter Elderson
>
> Op 12 jul. 2020 om 23:41 heeft Mike Thompson  het
> volgende geschreven:
>
> 
>
>
> On Sun, Jul 12, 2020 at 9:53 AM Peter Elderson 
> wrote:
>
>> Aren't Interstate and US evident from the geographic extent as well?
>>
> Yes, that is my point, or at least it is evident with the current mapping
> practice.  Road routes are not tagged (at least not according to the wiki)
> with network=nrn/rrn/etc.  Whether a road network is national, or
> otherwise, is evident for two reasons:
> 1) All the routes with the same network tag will be spread across some
> geographic extent. So, one could see that there are routes all across the
> US with "network=US:I" and could conclude that this is a national network.
> 2) By the network tag itself, for example, in the "network=US:I" tag,
> there is no smaller jurisdiction indicated after US, so it must be a
> national network.
>
> If a hiking route was tagged with network=US:FS (Forest Servies) for
> example, one could see that (if that practice was generally followed), that
> there the Forest Service operates hiking routes all across the US (and not
> anywhere else), and thus that such a network was national in scope.  And,
> the scope would be evident from the network tag itself, as there is no
> smaller jurisdiction following "US" in the network tag.
>
> In anyevent, my main point is we should be consistent and treat all route
> relations the same.  If it is desirable to explicitly know the scope, why
> not have a "scope" tag, or leave the scope in the network tag, and have a
> new tag for "specific_network" (or whatever folks want to call 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
>
___
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] network tag on route relations

2020-07-12 Thread Peter Elderson
Maybe just tag network=nfn then? Can be applied in any country. Details see 
oprator and ref.

How two distinguish two roads hundreds of miles away from each other? Hm... 
that is a hard question... 

Mvg Peter Elderson

> Op 13 jul. 2020 om 00:33 heeft Clay Smalley  het 
> volgende geschreven:
> 
> 
>> On Sun, Jul 12, 2020 at 3:08 PM Peter Elderson  wrote:
>> I still don't understand why you tag "US" while it's obviously a bunch of 
>> roads in the US. or Interstate when the road clearly crosses state lines. I 
>> think that"s more redundant than tagging "we classify this route as a 
>> regional route", even though it might cross two national borders in a few 
>> places and half the roads are outside our borders, and we don't know the 
>> current operator or provider.
> 
> Because they are two separate networks with roughly the same geographical 
> scope. How would you distinguish Interstate 30 from US Route 30, which are 
> hundreds of miles away from each other?
> 
> Some Interstate highways do not cross state lines themselves, but the idea 
> behind the name is that the network as a whole does. Regardless, that's just 
> the name for our national freeway network.
> 
> -Clay
> ___
> 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] network tag on route relations

2020-07-12 Thread Peter Elderson
Well, recreational routes and networks simply are not that organized, and 
jurisdiction or authority doesn't apply to most of them. I guess that is why 
the values are more generic. 

I still don't understand why you tag "US" while it's obviously a bunch of roads 
in the US. or Interstate when the road clearly crosses state lines. I think 
that"s more redundant than tagging "we classify this route as a regional 
route", even though it might cross two national borders in a few places and 
half the roads are outside our borders, and we don't know the current operator 
or provider.

Peter Elderson

> Op 12 jul. 2020 om 23:41 heeft Mike Thompson  het 
> volgende geschreven:
> 
> 
> 
> 
>> On Sun, Jul 12, 2020 at 9:53 AM Peter Elderson  wrote:
>> Aren't Interstate and US evident from the geographic extent as well?
> Yes, that is my point, or at least it is evident with the current mapping 
> practice.  Road routes are not tagged (at least not according to the wiki) 
> with network=nrn/rrn/etc.  Whether a road network is national, or otherwise, 
> is evident for two reasons:
> 1) All the routes with the same network tag will be spread across some 
> geographic extent. So, one could see that there are routes all across the US 
> with "network=US:I" and could conclude that this is a national network.
> 2) By the network tag itself, for example, in the "network=US:I" tag, there 
> is no smaller jurisdiction indicated after US, so it must be a national 
> network.
> 
> If a hiking route was tagged with network=US:FS (Forest Servies) for example, 
> one could see that (if that practice was generally followed), that there the 
> Forest Service operates hiking routes all across the US (and not anywhere 
> else), and thus that such a network was national in scope.  And, the scope 
> would be evident from the network tag itself, as there is no smaller 
> jurisdiction following "US" in the network tag.
> 
> In anyevent, my main point is we should be consistent and treat all route 
> relations the same.  If it is desirable to explicitly know the scope, why not 
> have a "scope" tag, or leave the scope in the network tag, and have a new tag 
> for "specific_network" (or whatever folks want to call 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] network tag on route relations

2020-07-12 Thread Peter Elderson
Suppose XXn for recreational networks should go.
What do I do with all the route relations neatly tagged as
lwn, lcn, lhn, lpn, ..,and the r..n, n.n and i.n ?

Removing the tags without a working alternative will clear a lot of charts
and maps which present the routes to users for navigation, information and
export.

There are many more of those routes than of the road routes.

I think such a proposal should be driven by something more than perceived
inconsistency*. Is there an actual pressing problem with the current
tagging?

* I do not share this view. The network is a text field and can have any
value indicating the network in a workable way. For roads, as I understand
it, an hierarchical/federative abbreviation system has been worked out, but
that is not valid for recreational routes. So these use a different
notation system, where for instance the country doesn't get named because
that is redundant. Also the particular numbering system doesn't go in the
network, but per network and operator in the ref (if present) or per area
in the colour tag. Numbers and colors are freely reused even within one
operator's network, so you can't catch this in a fixed hierarchy. Feel free
to try though.

Best, Peter Elderson


Op zo 12 jul. 2020 om 21:04 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 12. Jul 2020, at 20:32, Mark Wagner  wrote:
> >
> > The US has two national highway networks:
> >
> > * The Interstate Highway System, major high-speed roads connecting
> >  major cities.
> > * The United States Numbered Highway System (commonly referred to as
> >  the "US Highways"),
>
>
> that’s the norm elsewhere too, e.g. in Germany Autobahn and Bundesstraße
> or in Italy autostrada and strada statale, or in France autoroute and route
> national.
>
> IMHO we would not even need a network tag for these cases, as it is
> visible from the ref.
>
> 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] network tag on route relations

2020-07-12 Thread Peter Elderson
Aren't Interstate and US evident from the geographic extent as well?

If deducted from geographic extent, what would be the extent for local and
regional? Would the US need an interstate tag? Would a hiking trail through
a relatively small nature area crossing boundaries between countries, be
local, regional or international?

In Europe, the classification as local, regional, national and
international is very common with long trails/routes.Different countries
'map' their recreationale routes onto this classification. I think the
classification is useful.

The n in network=..n seems redundant, the .. is very useful and
seems to meet wide acceptance among users, the .. again looks
redundant to me because route= already gives the transport.

OTOH, what's the harm? A road network is not a recreational route network,
and therefore it has different network classifications. Does not confuse
me. At all.

Best, Peter Elderson


Op zo 12 jul. 2020 om 16:49 schreef Mike Thompson :

> Hello,
>
> According to the wiki[0], it seems that the network tag has different
> meanings and possible values based upon if it is applied to a route
> relation where route=road vs. route=bicycle/mtb/foot/etc.
>
> If I am understanding this correctly, when route=road, network= the
> specific network that the road is part of, for example, a US Interstate
> would be US:I[2]
>
> For bicycle/mtb/foot etc. it seems that the network tag indicates the
> scope of the network, for example a nationwide network cycling network
> would network=ncn[1]
>
> 1) Why can't the network tag have consistent meaning across all route
> types? For a mapper, as well as a data user, this is confusing.
> 2) The scope of a cycling/walking/etc. network should be evident from the
> geographic extent of its members, so isn't network=icn/ncn/etc. redundant?
> In any event, if the specific network is specified, it will, in most cases,
> also indicate the general scope.
>
> Mike
>
> [0] https://wiki.openstreetmap.org/wiki/Key:network
> [1]
> https://wiki.openstreetmap.org/wiki/Key:network#Bicycle.2C_hiking_and_other_recreational_routes
> [2]https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
> ___
> 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 - junction=intersection

2020-07-10 Thread Peter Elderson
Well, if you do a couple of intersections it's no big deal, but if every
intersection would need this and it breaks relations, no matter whose fault
it is, it is a problem. Then it's not just modeling, but forced repair
work. May be worth it, but I would like to know that at proposal time, not
by discovering all routes and turn restrictions are broken.

Just a consideration, if it doesn't break anything it's fine.

Best, Peter Elderson


Op vr 10 jul. 2020 om 16:50 schreef Matthew Woehlke <
mwoehlke.fl...@gmail.com>:

> On 10/07/2020 10.36, Peter Elderson wrote:
> > Question: does it break anything? I am thinking about existing relations
> of
> > various kinds.
>
> If splitting ways breaks relations, well, a) that's an editor problem,
> and b) I've already been breaking those left and right from splitting
> ways to improve accuracy of lane information.
>
> I don't see how it would break the *ability* to model anything, however.
> Given the above, I don't see how it could be meaningfully *harmful*.
>
> --
> Matthew
>
> ___
> 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 - junction=intersection

2020-07-10 Thread Peter Elderson
Question: does it break anything? I am thinking about existing relations of
various kinds.

Best, Peter Elderson


Op vr 10 jul. 2020 om 16:17 schreef Matthew Woehlke <
mwoehlke.fl...@gmail.com>:

> As some of you may recall, I'm working on a project to do traffic
> simulation with the help of OSM data and SUMO¹.
>
> One of the issues that SUMO has is that the typical method of modeling
> intersections (which I don't propose to change, mostly) results in SUMO
> thinking there are multiple intersections where there should only be
> one. For example, intersections of two dual carriageways produces four
> intersections and makes the turns much sharper than in reality.
>
> My use case isn't the only one that has issues with this sort of thing;
> routers can "see" more traffic lights than actually exist and can (so I
> hear, anyway) give directions that are potentially confusing.
> Intersection modeling is a long-standing issue that has had multiple
> previous proposals.
>
> The major two prior proposals of which I'm aware are to map the
> 'footprint' of the intersection as an area, or to create relations to
> map the intersection. Both are difficult, both to model, and for tools
> to parse. The area proposal has potential rendering issues.
>
> I am proposing² a *much* simpler alternative, which is to simply tag the
> portions of a road that are "part of" an intersection (i.e. the 'm',
> 'n', 'p', 'q' segments of
> https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with
> junction=intersection. This is straight-forward to model, and I believe
> solves most of the issues for a majority of affected intersections.
> (Exceptions likely exist, but 'perfect' is the enemy of 'good', and
> right now we're at 'bad'.)
>
> Comments would be appreciated!
>
> Also, should I start just doing this for the areas I'm trying to use for
> my project, or is it better to wait for some degree of consensus?
>
> (¹ https://www.eclipse.org/sumo/)
>
> (²
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection
> )
>
> --
> Matthew
>
> ___
> 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 - (Ground)

2020-07-10 Thread Peter Elderson
I think bare_soil or barren_soil are ok values for bare/barren soil.

I am convinced that these areas exist, bare soil without spontaneous
vegetation, whatever causes it to remain bare for many years.

Barren sounds to me to imply nothing can grow there.Bare sounds more
neutral and factual to me, it just says there is nothing but bare soil to
mark the area with.Please correct if I am wrong!

My preference would be the direct and factual *=bare_soil

The key does not really matter as long as it's not landuse, because it is
not a use of the land.
landcover=bare_soil sounds right to me.
natural=bare_soil might exclude areas which are bare because of human
causes. But it fits in with natural=bare_rock, and it is a sort of
null-option for vegetation from rain forest through grassy plains to
nothing growing there.
surface=bare_soil is not bad, but surface is generally used as an
additional key for a main feature, not a feature in itself.

Since soil is positively what you see, I don't think it's just negatively
defined. It's soil, with an important visible characteristic that it is
bare. Soil with vegatation has its own tags, but the absence of such a tag
does not indicate that it is bare soil.

All in all, I think natural=bare_soil is the best option, and that it fills
an important gap in the mapping of Earth's surface.

Question: How sure can you be from satellite imagery or aerial photography
that an area is actually bare soil?

Best, Peter Elderson


Op vr 10 jul. 2020 om 15:10 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> Jul 10, 2020, 15:04 by pla16...@gmail.com:
>
> I've just realized what prompted the back of my mind into writing the
> preceding paragraph.  landcover=barren (or natural=barren) seems
> to handle things nicely without worrying about soil/clay/humus
> distinctions.
>
> barren is horrible as it can be easily interpreted as including also paved
> surfaces,
> bare rock, areas with poor plant growth and many other cases
>
> as not a native speaker - natural=barren_soil seems more reasonable
> and harder to misinterpret
> (that specific combination may be horrible for grammar reasons,
> I am not a native speaker)
> ___
> 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 - (Ground)

2020-07-10 Thread Peter Elderson
Looks like humus is a component of soil. So I think soil covers it, being a
top layer consisting of mixed organic and mineral matter.

To me it is hard to imagine an area as permanently natural=bare_soil.
Wouldn't there always be some kind of vegetation within a year?


Best, Peter Elderson


Op vr 10 jul. 2020 om 12:42 schreef Michael Montani :

> I agree it could be considered as humus. The distinction between organic
> soil and humus is ambiguous according to
> https://en.wikipedia.org/wiki/Humus , but I think it is general enough to
> target mostly organic soil.
>
> Shall we consider to add this specification on the tagging? Or would humus
> be considered as bare soil anyway?
>
> Thanks
>
> --
> *Michael Montani*
> GIS Consultant, *Client Solutions Delivery Section*
> *Service for Geospatial Information and Telecommunications Technologies*
> United Nations Global Service Centre
> United Nations Department of Operational Support
>
> Brindisi | Phone: +39 0831 056985 | Mobile: +39 3297193455 | Intermission:
> 158 6985
> E-mail: michael.mont...@un.org  | www.ungsc.org
>
>
>
> --
> *Da:* Peter Elderson 
> *Inviato:* venerdì 10 luglio 2020 12:02
> *A:* Tag discussion, strategy and related tools  >
> *Oggetto:* Re: [Tagging] Feature Proposal - RFC - (Ground)
>
> Organic without any mineral, would you still call that soil?
>
> Vr gr Peter Elderson
>
>
> Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer <
> dieterdre...@gmail.com>:
>
>
>
> sent from a phone
>
> > On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Why it would be natural=bare_ground rather than natural=bare_soil?
>
>
> +1,
> I also disagree that “soil can be organic or mineral”. It has typically
> both, organic and mineral components, but organic components are a hard
> requirement. Otherwise it would be sand, or rock, or silt or clay or loam
> etc. (depending on grain size/s).
>
> 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


Re: [Tagging] Feature Proposal - RFC - (Ground)

2020-07-10 Thread Peter Elderson
Organic without any mineral, would you still call that soil?

Vr gr Peter Elderson


Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Why it would be natural=bare_ground rather than natural=bare_soil?
>
>
> +1,
> I also disagree that “soil can be organic or mineral”. It has typically
> both, organic and mineral components, but organic components are a hard
> requirement. Otherwise it would be sand, or rock, or silt or clay or loam
> etc. (depending on grain size/s).
>
> 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] Name for new wiki pages about roles of members in route relations?

2020-06-26 Thread Peter Elderson
The page describes a common role set  and comes with a tagging instruction,
for all types of recreational routes, except where a more specific role
set  has been approved.

It is *not* for other types of routes, such as PT routes, road routes, and
what have you, even though some role values may be used in e.g. functional
bicycle routes (bicycle speedways/preferred cycle routes).

I think it's not practical to repeat all of it on the pages of all the
route types within scope. Currently these pages refer to the proposal page
from a brief paragraph in the "how to tag" sections.

For example:
https://wiki.openstreetmap.org/wiki/Template:Tagging_scheme_for_hiking_and_foot_route_relations#Roles


Best, Peter Elderson


Op vr 26 jun. 2020 om 17:22 schreef Tobias Knerr :

> On 25.06.20 19:46, Joseph Eisenberg wrote:
> > Should individual pages for these roles be located at something like
> > Role:main and Role:alternative?
>
> So far, I believe roles are typically documented on the wiki page for
> the relation type, rather than their own pages. I don't think there's an
> established convention for wiki pages about individual roles yet.
>
> ___
> 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] Name for new wiki pages about roles of members in route relations?

2020-06-26 Thread Peter Elderson
What would be a proper example page for this? The
after-proposal-cleanup-procedure suggests the key:highway page, but that
does not seem appropriate for a role set.

Best,  Peter Elderson


Op vr 26 jun. 2020 om 13:25 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> Both versions seems fine to me.
>
> Jun 25, 2020, 19:46 by joseph.eisenb...@gmail.com:
>
> Since the proposal
> https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles
> was approved, there needs to be a new documentation page for the roles
> "main", "alternative", etc.
>
> Should individual pages for these roles be located at something like
> Role:main and Role:alternative?
>
> Or is it best to make up a new general page to describe them all, like "Roles
> for route relations
> <https://wiki.openstreetmap.org/w/index.php?title=Roles_for_route_relations=edit=1>
> "?
>
> – 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] Rail segment in a bike route

2020-06-24 Thread Peter Elderson
For the record, I think a transfer role is a generic solution  for the
issue raised here, applicable to the cable car transfer and other types of
transfer in routes, but I will not propose a new role value any time soon.

Anyone who wants to do it has my support, though.

Vr gr Peter Elderson


Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
> >
> > Normal OSM access is assumed to be access=yes, where some access is
> restricted then in OSM it should be marked *=no.
>
>
> for roads access=yes is assumed, it is not necessarily the default for all
> kind of features.
>
>
> 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] Are rowboats covered by "boat=*" or "canoe=*"?

2020-06-23 Thread Peter Elderson
Networks for canoes use network=lpn|rpn|npn|rpn where p stands for
paddling.
Hm, I fear that only complicates the matter...

Vr gr Peter Elderson


Op di 23 jun. 2020 om 14:05 schreef Niels Elgaard Larsen :

> Joseph Eisenberg:
> > The wiki page Key:boat <https://wiki.openstreetmap.org/wiki/Key:boat>
> says that tag
> > is to specify
> >
> > "Legal access restriction for boats. In the sense of OSM these are small
> boats and
> > pleasure crafts, including yachts."
> >
> > The picture shows a "no rowboats" sign: File:A.16_Fahrverbot.svg
> > <https://wiki.openstreetmap.org/wiki/File:A.16_Fahrverbot.svg>
> >
> > But there is also a key canoe=* - the page Key:canoe
> > <https://wiki.openstreetmap.org/wiki/Key:canoe> says:
> >
> > "Legal access restriction for boats without a motor or a sail like
> canoes, kajaks or
> > rowboats."
> >
> > I can see how canoes and kayaks are basically the same, since both are
> narrow boats
> > that usually carry 1 or 2 people and are propelled by paddles.
>
> And Stand Up Paddle?
>
> > But should rowboat access restrictions be under this key
> canoe=yes/no/designated, or
> > are they under boat=yes/no/designated - or something else?
>
> rowboats are not canoes.
> We are missing a more generic term.
> In the international rules it is "vessels under oars"
>
> I checked the tags in Denmark.
>
> Gudenåen and Skjern Å has canoe=permissive. But rowboats are also allowed
> (I have
> rowed on Gudenåen several times).
>
> Tåning Å has boat=yes, canoe=yes, motorboat=no
>
> There was also a floating pier tagged with canoe=yes.
> And that is probably not for rowboats. Clubs typically have different
> piers for
> rowboats and kayaks.
>
> I would say that we could have both "canoe" and "rowboat" and that both
> canoe and
> rowboat are also boat, just as e.g., hgv is also motor_vehicle.
>
> rowboats should not be canoes.
> In particular canoe=portage and canoe=put_in is wrong for rowing boats.
>
> Rowing clubs:
> https://agol.dk/elgaard/roklubber.html
>
> --
> Niels Elgaard Larsen
>
> ___
> 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

2020-06-19 Thread Peter Elderson
This
<https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Recreational_route_relation_roles#Transfer>
is
the talk page section I wrote about a week ago, for future consideration.

Fr gr Peter Elderson


Op vr 19 jun. 2020 om 14:33 schreef Peter Elderson :

> I think a bicycle route can not declare a rail route to be bicycle=yes. I
> think you should verify that the train is bicycle=yes before you call it a
> transfer. If it isn't, you can't declare it to be a part of your waymarked
> bicycle route, can you?
>
> Apart from that, if a router uses the bicycle route relation, it should
> alway check the ways themselves for access, no matter what the route
> relation says.
>
> Fr gr Peter Elderson
>
>
> Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli <
> franci...@gmail.com>:
>
>> Dear Volker and Peter,
>>
>> I agree with you both...
>> The question was born for a bike+train (funicular actually), but it can
>> be implemented in a generic way to fix similar cases.
>> Insead of interrupting the relation on the railway, we can put the other
>> public transport one as a member with a "transfer" role.
>> Of course, I assume the transfer relation will have 1 or 2 common points
>> with our trip (stops):
>> let's say a train starts from station A, but we take it at station B with
>> our bike, we get off at station C, but the last station will be Z.
>> I don't think this could be an issue, but should be considered for any
>> future implementation.
>> Transfer relations should also consider the parent's relation type (ex.
>> route=bicycle, implies bicycle=yes on the train route).
>> What do you think?
>>
>> Francesco
>>
>> ___
>> 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

2020-06-19 Thread Peter Elderson
I think a bicycle route can not declare a rail route to be bicycle=yes. I
think you should verify that the train is bicycle=yes before you call it a
transfer. If it isn't, you can't declare it to be a part of your waymarked
bicycle route, can you?

Apart from that, if a router uses the bicycle route relation, it should
alway check the ways themselves for access, no matter what the route
relation says.

Fr gr Peter Elderson


Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli :

> Dear Volker and Peter,
>
> I agree with you both...
> The question was born for a bike+train (funicular actually), but it can be
> implemented in a generic way to fix similar cases.
> Insead of interrupting the relation on the railway, we can put the other
> public transport one as a member with a "transfer" role.
> Of course, I assume the transfer relation will have 1 or 2 common points
> with our trip (stops):
> let's say a train starts from station A, but we take it at station B with
> our bike, we get off at station C, but the last station will be Z.
> I don't think this could be an issue, but should be considered for any
> future implementation.
> Transfer relations should also consider the parent's relation type (ex.
> route=bicycle, implies bicycle=yes on the train route).
> What do you think?
>
> Francesco
>
> ___
> 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

2020-06-18 Thread Peter Elderson
This issue is the same for routes for other modes of transport, especially
hiking.I know a hiking route using a bus transfer through a tunnel. I know
one in Switzerland using a train through a tunnel but only in winter. I
know one using a bus transfer for all cycling and hiking routes over a 30
Km long dyke. And lots of ferries over rivers and lakes.
I know canoe routes with foot sections (portage).

I would keep the solution as generic and as simple as possible.

As it happens, a basic functional role set has recently been approved for
such routes.It assigns a rol to approaches, excursions, alternatives and
connections between routes.

I was thinking about adding a role "transfer", to be assigned to a member
relation. The relation that gets the role "transfer" is a route relation of
a different transport mode. It's all the information you need, so there is
no need for transport mode specific roles.

There is one complication to be considered: the different type of roles
cannot be combined in one relation. Especially for cycling, a particular
way of the route could have the forward|backward role, belong to an
alternative|approach|excursion|connection, and belong to a transfer
section, all at the same time.
A relation member cannot have the forward|backward role, but it could be
both transfer and one of the approved basic role set.

This complication can always be solved within a relation hierarchy, though.

Best,  Peter Elderson


Op do 18 jun. 2020 om 21:58 schreef Volker Schmidt :

> I know several bicycle route segments on water: ferryboat, waterbus,
> private on-demand boat.
> On rail: One route contained a normal rail segment.
> By Bus: scheduled buses on road segments with heavy traffic.
> We should consider these other means as well in any proposal.
> :
>
> On Thu, 18 Jun 2020, 20:32 Francesco Ansanelli, 
> wrote:
>
>> Dear all,
>>
>> I discussed with local mappers about the need of a role "take_train" or
>> "public_transport" to fix bicycle routes...
>> Would anybody be so kind to make a proposal about this post?
>>
>> Many thanks
>> Cheers
>> Francesco
>>
>> Il giorno lun 16 dic 2019 alle ore 13:49 Francesco Ansanelli <
>> franci...@gmail.com> ha scritto:
>>
>>>
>>>
>>> Il lun 16 dic 2019, 10:56 Warin <61sundow...@gmail.com> ha scritto:
>>>
>>>> On 16/12/19 20:21, Martin Koppenhoefer wrote:
>>>>
>>>> Am Mo., 16. Dez. 2019 um 10:02 Uhr schrieb Volker Schmidt <
>>>> vosc...@gmail.com>:
>>>>
>>>>> Can we come back to talking about a solution.
>>>>> Maybe an appropriate new role value could be a solution:
>>>>> role=take_train on the corresponding train section in the bicycle route,
>>>>> for example.
>>>>> However, this would provide an easy way to add train ride details.
>>>>>
>>>>
>>>>
>>>> I would add the train route relation as member, rather than the
>>>> individual railway ways.
>>>>
>>>> If the entire train route is used then ok. But if only a section is
>>>> used then I think the relevant ways only should be included.
>>>>
>>>> If a simple dataconsumer is not aware, it would should a hole in the
>>>> bicycle relation (what IMHO is a good way to show that there is something
>>>> special, in particular that you cannot simply ride your bike there), while
>>>> a data consumer who specifically understands the situation could give
>>>> specific directions. I agree a specific role also seems reasonable (could
>>>> be extended to ferries, trams, aerialways, etc.)
>>>>
>>>>
>>>> role=take_train would not work for ferries, buses, canoes etc.
>>>>
>>>>
>>>> I think role=transport could work .. provided the way identifies what
>>>> form of transport is used ... that could be a problem for bus routes?
>>>>
>>>> role=transport_train/transport_bus???
>>>>
>>>
>>>
>>> I agree with the 'transport' name, it's the same I was thinking too...
>>> Also 'transport_relation' could be fine.
>>> Since you are adding a relation as segment you will get the type of
>>> relation from it.
>>> At this point I'd remove all information from the rail, do a relation
>>> ptv2 and add that to my 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
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature proposal - Voting result - Recreational Route Relation Roles

2020-06-17 Thread Peter Elderson
https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles


Voting was open from 2020-06-03 through 2020-06-16. The proposal was
*approved* with 36 votes for, 1 vote against and 1 abstention.

Thanks to everyone who voted and/or participated in the discussion.
Special thanks @Mfbehrens99 for your initial efforts.

Some of the comments in the votes and on the talk page warrant a change of
wording, for clarification. I will do that without further discussion when
I find the time.


Post-vote clean-up says "A new page for the feature should be created and
the relevant map features template
<https://wiki.openstreetmap.org/wiki/Category:Features_template> (depending
on whether it is a key, a value, or a relation) should be applied. "

Since it was neither key, value, nor relation, I am not sure if a new page
has to be created, or maybe just do a textual clean-up and add links to
relevant feature pages?

Best, Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Compliments and thanks to the "iD people"!

2020-06-12 Thread Peter Elderson
(Not directly a tagging issue, but very often mentioned here, and rarely in
a positive way!)

I would like to thank the iD developers for their work on keeping route
relations right when changes are made to the ways.

I was very negative about that because I spent a lot of time repairing the
damage caused by iD-users who just didn't know what was going on with route
relations. I remained sceptic when I heard work had been done: see first,
then believe. And I was not the only one.

At this point, when I check a long distance hiking route for errors, I
hardly find any errors caused by mappers. The ones I find are not typically
caused by iD-use; JOSM appears just as often the cause. So it's really down
to mapper error now.

I am finally convinced. My compliments and thanks again!

(I still have a lot of wishes when it comes to managing relations online,
but that's another chapter!)

Best, Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-09 Thread Peter Elderson
The dictionary doesn't help much: track:  "a path
<https://dictionary.cambridge.org/dictionary/english/path> or rough
<https://dictionary.cambridge.org/dictionary/english/rough> road
<https://dictionary.cambridge.org/dictionary/english/road> that is made of
soil <https://dictionary.cambridge.org/dictionary/english/soil> rather
<https://dictionary.cambridge.org/dictionary/english/rather> than having a
surface <https://dictionary.cambridge.org/dictionary/english/surface>
covered <https://dictionary.cambridge.org/dictionary/english/cover> with
stone <https://dictionary.cambridge.org/dictionary/english/stone> or other
material <https://dictionary.cambridge.org/dictionary/english/material>"

path:
a route or track between one place and another, or the direction in which
something is moving:
a garden path
a concrete path
a well-trodden path
This is the path to the cliffs.
It will be several days before snowploughs clear a path (through) to the
village.
They followed the path until they came to a gate.

So this
https://www.mapillary.com/app/?lat=51.9940387923=4.707510424794445=17=photo=pV1y2lcTNq-jB7xvJNONTQ
cannot
be a track. It must be a path.

Best, Peter Elderson


Op wo 10 jun. 2020 om 00:13 schreef Tod Fitch :

>
>
> On Jun 9, 2020, at 2:22 PM, Mike Thompson  wrote:
>
> On Tue, Jun 9, 2020 at 3:02 PM brad  wrote:
>
>> A track does have a different function, it can handle a 2 track vehicle,
>> a path can't.
>>
> Yes, a "track" has a different function, its function is for agriculture
> or forestry.
>
> A wide path on the other hand has the same function as a narrow path.
>
>
>> If functional is sacrosanct,  why do we have motorway?   A motorway could
>> just be a trunk or primary with extra tags denoting limited access.
>>
> That is a good question.  But it was stated on this list just a couple of
> weeks ago that the highway=* tag was a functional classification, "except
> for motorway"
>
>
> In my rendering of hiking maps I currently have to look at 13 tags and
> their values to make a decision if a “path” or “footway” might be what I
> want to render. This is ridiculous. It is neither easy for the mapper nor
> the renderer.
>
> On the motor vehicle side this would be the equivalent of saying all ways
> intended for cars should be mapped as highway=road and we can distinguish
> them by using surface, width, smoothness, maximum speed, etc.
>
> I think we need some more values for the highway tag that would allow a
> mapper to easily tag:
>
> 1) A narrow rural trail where you probably want good footwear and are
> likely to take a small pack with water, snacks, etc.
> 2) A smooth hard surfaced walk, usually in or near urban/suburban areas)
> suitable for pushing a stroller.
> 3) A wide fairly smooth way (usually in or near urban/suburban areas)
> designed for getting exercise. Probably not paved, but with a natural
> appearing surface that is maintained to be fairly smooth.
>
> In my part of the world many of those things are general purpose (mixed
> foot and bicycle use and often horses). Mappers end up using highway tag
> values of path, footway, track, and, rarely, cycleway or bridlepath. If we
> are lucky they might put a surface tag or some access tags on it. It is a
> mess. Hard for a beginning mapper to decide what tags to use. Hard for a
> data consumer to figure out what the mapper was trying to map.
>
> The two major factions seem to be set in their ways: “It is only a track
> if it is used for agriculture or forestry” on one side. “It has the same
> physical characteristics as a track, so it is a track even if it is
> currently used for hiking, bicycling, riding horses, or by ATVs” on the
> other side.
>
> That also spills into is it a track or a service (driveway)? Depends on if
> it goes to a barn or a house! But I can’t tell without trespassing, how can
> I map it?
>
> First step, I think, is to be less pedantic about function on things that
> look exactly like a track. Mappers in all the areas I’ve looked at will tag
> a way that is unpaved and about the width of a four wheeled vehicle as a
> track regardless of current use. Maybe it is being used as a driveway.
> Maybe it is being used as a bicycling/hiking/equestrian trail. Maybe it
> accesses a field. Maybe it hasn’t been used for a while and just hasn’t
> decayed or been overgrown into nothing. Who knows? But it looks like a
> track. Saying that the way “isn’t for forestry or agricultural use” so it
> can’t be a track is worthless: Real world mappers have voted otherwise with
> their tagging.
>
> Cheers!
> Tod
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature proposal - Voting - Recreational route relation roles

2020-06-03 Thread Peter Elderson
Voting has started! Voting is open till 2020-06-17.

https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles


The proposal will not change during voting. I will answer clarifying
questions. Comments, even if it's just about wording or examples and
doesn't change the proposed roles, will be considered after the voting.

Thanks everyone for useful comments and suggestions so far. I am confident
we will get this improvement done.

I know some people had expected more. And I agree! Even then, please vote
yes to this basic proposal, it lays the groundwork for things to come.


Best, Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

2020-06-01 Thread Peter Elderson
Thanks, I will have a go. Probably it's not that hard.

Best,  Peter Elderson


Op ma 1 jun. 2020 om 11:49 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> Jun 1, 2020, 10:03 by pelder...@gmail.com:
>
>
> Just a reminder: in a few days voting will start (if I can figure out how
> to do that...).
>
> See
>
> https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
>
> and a real example:
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Lines_management=1994346=1994343
>
> if you have problems - which part of instructions is unclear?
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   3   4   5   6   >