Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

I personally think such should still be tagged as long as the space, or the
right of way, still remain, but not when it have been completely removed,
integrated into surrounding area, and redeveloped, unless traces or marks
of either the remain of the rail system itself or the space previous used
by the rail can still be found despite redevelopment.

在 2020年5月25日週一 13:06，Joseph Eisenberg  寫道：

> This was originally sent to the Talk mailing list, but it is better if it
> is discussed on the Tagging mailing list:
> https://lists.openstreetmap.org/listinfo/tagging
>
> I agree that razed, completely demolished railways, where all traces of
> the former track-bed have been removed, should be removed from
> OpenStreetMap.
>
> It is still considered acceptable to map abandoned railways, where the old
> railway grade remains, even though the metal rails have been removed.
>
> However, note that there are some people who are very committed to mapping
> historical and abandoned railways, so there may be resistance to removing
> these features.
>
> See the long discussions about rendering railway=abandoned at
> https://github.com/gravitystorm/openstreetmap-carto/pull/542 and
> https://github.com/gravitystorm/openstreetmap-carto/issues/586 for
> example.
>
> Also see the previous discussion at
> https://wiki.openstreetmap.org/wiki/Talk:Railways#Abandoned_railways_where_all_evidence_has_been_removed
>
> – Joseph Eisenberg
>
> On Sun, May 24, 2020 at 9:40 PM Jack Armstrong 
> wrote:
>
>> Greetings.
>>
>>
>> Recently, a user mapped “razed” railways inside a construction zone (link
>> below). These rails had been removed by our local mappers since they don’t
>> exist anymore. Using the latest imagery (Maxar), you can see the rails have
>> been completely removed from “Project 70”, a $1.2 billion Denver-area
>> transportation corridor construction project.
>>
>>
>> I think this mapper has good intentions, but what is the point of mapping
>> something that does not exist? Doesn’t this clearly contradict the OSM Good
>> Practice wiki in regards the sections, “Verifiability”, “Map what's on the
>> ground” and “Don't map historic events and historic features”? The last
>> section states, "*Do not map objects if they do not exist currently*."
>>
>>
>> Should we tag (invisible) razed sidewalks? Should we leave (invisible)
>> destroyed buildings in place, tag them as razed and then create new
>> buildings on top of them?
>>
>>
>> https://www.openstreetmap.org/edit#map=19/39.78016/-104.94562
>>
>>
>>
>> ___
>> talk mailing list
>> t...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Martin Koppenhoefer]

sent from a phone

> On 25. May 2020, at 07:06, Joseph Eisenberg  
> wrote:
> 
> It is still considered acceptable to map abandoned railways, where the old 
> railway grade remains, even though the metal rails have been removed. 


As a side note these are “dismantled” railways, while abandoned railways have 
the metal rails still more or less in place

Cheers Martin 



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Martin Koppenhoefer]

sent from a phone

> On 25. May 2020, at 08:54, Colin Smale  wrote:
> 
> 1. Live and let live - OSM has always been a broad church. It might not be 
> your hobby, but it is their's. The bar to actively deleting other people's 
> work should be set very high indeed.
> 

+1
I completely subscribe to this 

Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Florian Lohoff]

Hola,

On Mon, May 25, 2020 at 08:52:21AM +0200, Colin Smale wrote:
> 1. Live and let live - OSM has always been a broad church. It might not
> be your hobby, but it is their's. The bar to actively deleting other
> people's work should be set very high indeed. 

I subscribe to this aswell. As long as it does not collide with stuff
in use we should be able to tolerate data of historic or special purpose
most of us probably do not aim for.

The broad scope of your subject must otherwise be answered with: "No"

It IS Best Common Practice to follow the "On the ground" rule with only
very few exceptions.

And IMHO we cant lift that. OSM needs to have a common ground to discuss
matters and sometimes reality is already pretty hard to agree on. If we
now add stuff in history or in the minds of mappers we open a pretty
difficult can of worms.

So - To quote from Postels Law - On of the inventors of the Internet:

"Be conservative in what you do, be liberal in what you accept from others"

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Florian Lohoff]

On Mon, May 25, 2020 at 01:48:20AM +0200, Mateusz Konieczny via Tagging wrote:
> >
> Wrong tagging is not interesting by itself.
> 
> I was looking for real-world situation where 
> 
> (1) there is some seemingly good overcomplicated tagging
> (2) there is a good and simpler replacement


The classic case is that people to not use "vehicle" or "motor_vehicle"
but tag all individual subtypes individually, sometimes even
with their parent.

So there is no need for

motorcycle=destination
goods=destination
hgv=destination
car=destination
mofa=destination

When there is a "motor_vehicle=destination"

Some mappers live under the impression that the more they tag the
better. So it is important to tell them to match the best and most exact
scope of the signage. 

Most signs just exclude all vehicles or all motor_vehicles. So no needs
to list them individually. We have a tag for that.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 5/25/20 3:42 AM, Warin wrote:


You will need to be very clear what a 'common' is and how it is 
different from other tags such as amenity=marketplace, leisure=park


The defining characteristics are: being open to public, not designated 
for a specific purpose, not landscaped (or that would be a park), not a 
marketplace (in West Africa, marketplaces are regulated and occur almost 
only at designated locations), not a pitch (when a couple pairs of 
goalposts are planted at extremities, the pitchness sometimes takes 
precedence and a few such locations are rightfully mapped as soccer 
pitches - but usually playing ball is just one of the uses of such places)


A possible alternative, not yet mentioned here, is place=square (which 
by the way is the English for the concept of piazza/plaza) "A town or 
village square: a paved open public space, generally of architectural 
significance, which is surrounded by buildings in a built-up area such 
as a city, town or village" - 
https://taginfo.openstreetmap.org/tags/place=square 
https://en.wikipedia.org/wiki/Town_square - but it is part of the 
place=* hierarchy, which is not fit for our purpose: place=* requires a 
name=* and this places are rarely named.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Colin Smale]

On 2020-05-25 10:39, Florian Lohoff wrote:

> On Mon, May 25, 2020 at 01:48:20AM +0200, Mateusz Konieczny via Tagging 
> wrote: 
> 
>> Wrong tagging is not interesting by itself.
>> 
>> I was looking for real-world situation where 
>> 
>> (1) there is some seemingly good overcomplicated tagging
>> (2) there is a good and simpler replacement
> 
> The classic case is that people to not use "vehicle" or "motor_vehicle"
> but tag all individual subtypes individually, sometimes even
> with their parent.
> 
> So there is no need for
> 
> motorcycle=destination
> goods=destination
> hgv=destination
> car=destination
> mofa=destination
> 
> When there is a "motor_vehicle=destination"

Is there a uniform definition of "motor_vehicle" in terms of its
constituent vehicle classes? Do the constituent classes also have a
uniform definition? A problematic example is "psv" where its status is
not simply a function of the vehicle's construction or taxation class,
but also of the use to which it is being put. If a taxi driver takes his
taxi on holiday? A bus running empty back to the depot? This is going to
depend on the specific jurisdiction. How we word the definition of the
OSM tag is of major importance if we are to avoid endless arguments
about these edge cases. 

Interesting fact: in NL, speed limits don't apply to cyclists, because
the law says that speed limits are for motor vehicles. Is an eBike a
"motor vehicle"? Do we need "maxspeed:cycle=none"? BTW this is
rhetorical - just mentioning it here to illustrate how easily we can
project our own bit of the world onto the whole planet and assume it's
the same for everyone.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[John Willis via Tagging]

Javbw

> On May 25, 2020, at 1:28 PM, Andrew Harvey  wrote:
> 
>> We do have that: `sac_scale=hiking`

And that is a good example of bad tagging I want to correct. 

There are more people walking local wilderness trails with their dog in a 
single day than all “backpackers” on earth in a year. Few-to-none of these are 
“day-hike” or “trekking” routes, yet they are most definitely “trails”. I do 
not need to know the sac scale to tag it as a trail. 

And How are those routes “hiking”? There are plenty of trails not meant for 
hiking. Hiking is a leisure pastime. A trail is type of way. 

I can tag a track without defining it’s tracktype=* it’s a track - _and then_ 
further defined by tracktype=* .

Do I have to know the width to tag a road? Do I need to know the number of 
stairs or the incline of the steps to tag it as steps? 

No. 

It’s a residential road. Steps. A cycleway. A trail. 

The attributes of the way do not define it as that type of way - a named tag 
anyone can use does, including someone who can’t define its sac scale - or has 
no idea what the heck that is. 

Trails should Have _never_ been lumped in with path. It was a _horrible_ 
decision, like motorways and driveways sharing a main tag because cars use 
both. 

At least sub-tagging them to be able to easily separate them _and then_, when 
possible define further characteristics __when possible__ with more specific 
tags, like sac scale. 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Andrew Harvey]

On Mon, 25 May 2020 at 19:44, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
> Javbw
>
> On May 25, 2020, at 1:28 PM, Andrew Harvey 
> wrote:
>
> We do have that: `sac_scale=hiking`
>
>
> And that is a good example of bad tagging I want to correct.
>
> There are more people walking local wilderness trails with their dog in a
> single day than all “backpackers” on earth in a year. Few-to-none of these
> are “day-hike” or “trekking” routes, yet they are most definitely “trails”.
> I do not need to know the sac scale to tag it as a trail.
>
> And How are those routes “hiking”? There are plenty of trails not meant
> for hiking. Hiking is a leisure pastime. A trail is type of way.
>

But how would you define what a trail is?

Up in this thread Daniel noted some definitions, but I think that needs to
be written up as a proposal for where it would apply.

According to the Cambridge dictionary, a trail is "a path through a
> countryside, mountain, or forest area, often made or used for a particular
> purpose:
> - a forest/mountain trail
> - a walking/snowshoeing/cross-country skiing trail"
> Other dictionaries use "beaten path", "a track made by passage especially
> through a wilderness" or similar.
>
> To me, the main difference is between a beaten path vs a path that has
> been purposely groomed.




I can tag a track without defining it’s tracktype=* it’s a track - _and
> then_ further defined by tracktype=* .
>
> Do I have to know the width to tag a road? Do I need to know the number of
> stairs or the incline of the steps to tag it as steps?
>
> No.
>
> It’s a residential road. Steps. A cycleway. A trail.
>
> The attributes of the way do not define it as that type of way - a named
> tag anyone can use does, including someone who can’t define its sac scale -
> or has no idea what the heck that is.
>
> Trails should Have _never_ been lumped in with path. It was a _horrible_
> decision, like motorways and driveways sharing a main tag because cars use
> both.
>
> At least sub-tagging them to be able to easily separate them _and then_,
> when possible define further characteristics __when possible__ with more
> specific tags, like sac scale.
>

I get your point, and agree, but for highway=footway there is a definition
on the wiki of what that covers, same for cycleway, residential road,
highway=track, etc. we don't just say tag a track as highway=track.

For example around me a "Fire Trail" is tagged as highway=track, and a
"Track" (as in a remote forest/bush walking path) is tagged as
highway=footway/path (probably what you're proposing as "trail". So we need
definitions that can be applied globally regardless of how things are
locally known and across languages.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Mateusz Konieczny via Tagging]

May 25, 2020, 11:06 by colin.sm...@xs4all.nl:

>
> Is there a uniform definition of "motor_vehicle" in terms of its constituent 
> vehicle classes? Do the constituent classes also have a uniform definition? A 
> problematic example is "psv" where its status is not simply a function of the 
> vehicle's construction or taxation class, but also of the use to which it is 
> being put. If a taxi driver takes his taxi on holiday? A bus running empty 
> back to the depot?
>
>
And that is why psv is useful. Lets say that in given territory it applies to 
bus on route with public
and scheduled traffic and it does not apply to bus running service that is not 
accessible to public.

It is impossible to tag such difference using vehicle class tags.

Similarly, if one see "public service vehicles allowed" (or in Poland "nie 
dotyczy pojazdów
transportu publicznego") psv allows one to tag it without detailed knowledge 
how to create
massive complicated restriction that would use conditional syntax.

>  This is going to depend on the specific jurisdiction.
>
Yes, routers need some are-relevant info and ask user to provide routing 
matching law.

>  How we word the definition of the OSM tag is of major importance if we are 
> to avoid endless arguments about these edge cases.
>
+1 - that is main benefit of proposal process, you may avoid this before tags 
gets popular

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Mateusz Konieczny via Tagging]

May 25, 2020, 09:47 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 25. May 2020, at 08:54, Colin Smale  wrote:
>>
>>
>> 1. Live and let live - OSM has always been a broad church. It might not be 
>> your hobby, but it is their's. The bar to actively deleting other people's 
>> work should be set very high indeed.
>>
>>
>
> +1
> I completely subscribe to this 
>
+1, but something that is 100% gone can be deleted.

I have seen railway=abandoned mapped across open-pit mine that was there for 20 
years.

There was zero chance of mappers recreating it (as oldest aerials will show 
open pit mine),
it was 100% gone (like embankments, railway station and dirt 20 m below).

I deleted it.

Something that is fully, completely and totally gone can be deleted. If there 
are buildings
across former track of the railway and embankment is leveled then it can and 
should
be deleted.

If there are no traces whatsoever and you need old maps to map it then it is 
out of
scope of OSM and deleting it improves OpenStreetMap.

There was railway here:
https://commons.wikimedia.org/wiki/File:National_Museum_in_Krakow-Main_Building,_1,_3Maja_Av,_Krakow,Poland.jpg

There are no traces whatsoever. It is not mapped, should not be mapped and
should be deleted if mapped.

I have more doubts about cases where only earthworks remain (and are used for
cycleway/road/path). You can plausibly guess that railway was there but it is 
just a
guess and typically you need old maps to confirm that it was there.

And in some cases such features look like former railway but that is not really 
true.

But something that is totally gone should be gone from OpenStreetMap (with 
exceptions
for objects marked as gone and temporarily not deleted to prevent incorrect 
remapping).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Change of wiki page Key:access

[Florimond Berthoux]

I have encounter this issue many times : reality vs traffic sign.
No vehicle acces to the wood in Paris, except that cyclist go there and
that normal.
A living street sign on a transit road.
Etc.

I would like to be able to tag separately the sign/law and the 'on the
ground' reality.

For the default I'd say tag the reality if there almost no change to be
blamed for violating the sign.

So for me the new tag would be
motor_vehicle=no
bicycle:dejure=no

Or if there is a little change to be blamed, bicycle:defacto=yes is nice
too.

Could work also for highway :
highway=tertiary
highway:dejure=living_street

Le lun. 25 mai 2020 à 00:30, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

>
>
>
> May 24, 2020, 23:42 by vosc...@gmail.com:
>
> The strict wording introduced by Florian is simply not practically
> applicable here.
> My questions are:
> Is Italy the only country with this problem?
>
> Poland used to be similar, though police sometimes setup trap where they
> were fining people -
> in sudden campaigns with several traps appearing for several hours every
> few months.
>
> Favorite traps included cycleways crossing roads, where cyclists were
> obligated by law to dismount
> due to missing cyclist crossings.
> Some routes had such crossing every 200 - 250m, nobody was following that
> law.
>
> I was tagging legal status, and had some discussions with other mappers
> whatever it is desirable to do it this way.
>
> Currently most of missing cyclist crossings are added[1], signs (for
> example in forests)
> more commonly explicitly allow bicycles, oneway:bicycle=no is becoming
> more common
> at least in some cities...
>
> [1] It turned out that blocker was completely idiotic law requiring
> pedestrian + cyclist crossings
> to be at least 7 m wide, for smaller ones including cyclist crossing was
> against rules.
>
> Is there any better proposal for tagging the situation "from all I can see
> on the ground, you are allowed ride through with your bicycle"
>
> Not sure what I would do in cases where access law as written and access
> law as executed
> would completely diverge.
>
> Setup new tags specially to allow to tag both verifiable legal status and
> verifiable
> de facto status?
>
> bicycle=no
> bicycle:de_facto=permissive
>
> (even bicycle=permissive, bicycle:ignored_law=no would be an improvement
> over
> current state of not tagging legal status)
>
> It is out of OSM scope but I also had some successes with requests to add
> missing
> "except bicycles" under various traffic signs (on average in last years -
> about one added every month),
> in some cases it was simpler than inventing fitting tagging scheme for
> really absurd cases.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Florimond Berthoux
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Daniel Westergren]

>
> For example around me a "Fire Trail" is tagged as highway=track, and a
> "Track" (as in a remote forest/bush walking path) is tagged as
> highway=footway/path (probably what you're proposing as "trail". So we need
> definitions that can be applied globally regardless of how things are
> locally known and across languages.
>

You're touching a very important topic here, linguistics. We use different
terms in different parts of the globe. And a path has in English a much
wider meaning than when translated to other languages, like Swedish.

In Swedish we have basically "*väg", *which would translate to road or way,
while "*stig" *would translate to footpath/path/trail, basically what we're
discussing here, i.e. the narrower definition of path.

   - bil*väg*: car road (or "car way")
   - bruks*väg*/skogs*väg*/jordbruks*väg* (= track)
   - cykel*väg*: cycleway
   - gång*väg*: footway (= part of the official network)
   - gång*stig *or simply stig (as it can just as well be used for MTB
   etc.).

My point is that there is a linguistic different between different kinds of
"väg", all of which are part of the officially built road/cycleway/footway
network vs naturally created paths/trails. The use of highway=path for both
these purposes is probably the main confusion for me.

Sure, there is a greyzone for cases like purposely built, often
urban/semi-urban, "natural paths" or paths that have been groomed to
increase their accessibility for visually impaired, wheelchairs, children
etc. But as has been mentioned in this thread, those greyzone cases are
minor compared to the overall problem of the lack of this distinction.

Sorry for having caused a very long, but certainly very interesting and
engaging thread on this never-ending topic. If it was discussed this way 12
(?) years ago, things would have been simpler. I understand the consensus
as although it would have been good, it's probably too late for a separate
highway tag for "trail" or whatever we call it and the only way forward is
a subtag like "highway=trail"? Although what we need then is a clear
definition of what it is and a way to handle all the cases when this subkey
will not be used.

For such a definition we probably need people from many different countries
chipping in, to make it clear enough for all languages and locations.

/Daniel






> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Mateusz Konieczny via Tagging]

Discussion moved from talk mailing list as it is clearly about tagging details.

Relevant part is quoted so hopefully it is not too confusing.

May 25, 2020, 02:45 by a...@thaw.de:

> On 25 May 2020, at 01:45, Mateusz Konieczny via talk  
> wrote:
>
>> May 25, 2020, 00:36 by a...@thaw.de:
>>
>>>
>>> I would argue that non-gated driveways are often closer to 
>>> access=destination than they are to access=private.
>>>
>>> According to the wiki, private requires individual permission, which I 
>>> can't give to the mailman / delivery person, but I still want them to make 
>>> their deliveries on my doorstep.
>>>
>> I would describe delivery part as
>>
>> "I have given individual permission to delivery person by requesting 
>> delivery"
>>
>
> Not all deliveries are actively requested, and the delivery person can't know 
> if you requested it or not. 
>
Good point. Maybe it can be argued that there is implicit permission for 
delivery services?
My uncle has farm, with clearly private yard (it is unsigned).

Postman or package delivery would be welcomed there and - even if package 
would not be requested, but random person driving to
front of his house would not be and AFAIK would violate law.

> Therefore, access=private as a _default_ for driveways seems wrong to me.
>
Here I completely agree. That is why we tag access=private if needed on 
driveway,
and access=yes is basically never tagged.

This indicates that we treat "public access" as default value for all highway 
levels,
including driveways.


>> Random person driving to my house and trying to sell me random items would
>> not be covered by such permission and unwanted and violating access rules,
>> right?
>>
>> Such peddler would be allowed by access=destination (any non-transit
>> traffic allowed).
>>
>
> Exactly. In the jurisdictions I'm familiar with, such traffic is in fact 
> generally allowed on driveways.
>
> However, some driveways are behind a locked gate or clearly signed as 
> "private / no trespassing" (which is legally equivalent in some 
> jurisdictions). Such cases should qualify for an _explicit_ access=private 
> tag. Delivery to your doorstep might then be impossible, unless there's like 
> a bell at the gate that can be used by the delivery person to obtain 
> individual permission.
>
Sounds OK.

> So, access=private for driveways is not necessarily wrong, it's but probably 
> somewhat rare.
>
I would be careful with "somewhat rare" - it strongly depends on location,
in Poland overwhelming majority (nearly 100% outside rural areas) of driveways
will have gates.

> Your new language about this on the access=* page seems fine to me:
> https://wiki.openstreetmap.org/w/index.php?title=Key:access&oldid=1994851#Road_with_restricted_access
>
:)

> FWIW, I'm less happy with the current state of the access=private page. But 
> I'm not sure if consensus exists to clarify it.
>
What is wrong and how you want to change it?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Tagging-fr] [Talk-ml] [Talk-sn] With leisure=common deprecated, Senegal & Mali need a replacement

[Marc M.]

there's an *observation* that this tag has different meanings,
from a few blades of grass between 2 streets to a paved surface
for the big annual village party.
Do you dispute that *statement* ?
or do you want to deny it and repeat that only your meaning should
be taken into account ?
If you use it in your neighborhood, your own application may decide that
your meaning is the only common sense, but on a global level, this can't
succeed.

You seem to be talking about depreciation as if there was a voting
procedure, whereas in this case it's more like "these multiple meanings
make the tag unusable worldwide, fortunately there are less ambiguous
alternatives".

Le 25.05.20 à 00:19, Rafael Avila Coya a écrit :
> Unless you demonstrate me that I am wrong, the tag leisure=common was
> deprecated without any agreement with the community. So it's clearly not
> a deprecated tag. Another thing is what you actually think about the tag
> itself.
> 
> Cheers,
> 
> Rafael.
> 
> O 23/05/20 ás 20:49, Marc M. escribiu:
>> Agree on what?
>> That leisure=common needs a replacement ? Yes.
>> that replacement must be different from what needs to be replaced ?
>> it seems logical to me but some people think that replacing a
>> depreciated tag by itself will solve the problems that led to its
>> depreciation.
>>
>>
>> Le 22.05.20 à 15:46, Jean-Marc Liotier a écrit :
>>> So, we are actually all in agreement, aren't we ?
>>>
>>> Nous sommes donc tous d'accord, non ?
>>>
>>>
>>> On 5/3/20 6:00 PM, severin.menard wrote:
 Oui désolé, en effet je me suis trompé sur la clé !

 Yes sorry, my mistake regarding the right key!



 ‐‐‐ Original Message ‐‐‐
 Le dimanche 3 mai 2020 17:54, Pierre Béland via Talk-ml
  a écrit :

> Fr
>
> Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin,
> je disais bien
>   leisure=common
>
> En
>
> Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did
> say...
>   leisure=common
> */ /*
>
>
> Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier
>  a écrit :
>
>
> So, this discussion gravitates towards using landuse=common for those
> African urban freely accessible multipurpose open spaces, which I
> fully support.
>
> Implementing this change requires the following actions:
>
> - Editing the leisure=common wiki page, in French and in English
> (I'll do that)
>
> - Reinstating the rendering of leisure=common in downstream
> cartographic styles, would be even better if the color matched the
> surface=* so that sandy surfaces don't appear green.
>
> - Reinstating the rendering of leisure=common in JOSM's default style
> (it recently changed to grey to mark deprecation). (I'll open a JOSM
> ticket
>
> - Altering QA rules (JOSM Validator and Osmose) so that the
> leisure=common deprecation only applies to the United Kingdom of
> Great Britain, where commons have a legal definition and
> designation=common must be used for them. (I'll open a JOSM ticket
> but if someone has prior experience interacting with the Osmose
> people, that would be nice)
>
>>> ___
>>> Tagging-fr mailing list
>>> tagging...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging-fr
>>>
>>
>> ___
>> 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] Adding values healthcare=dispensary and healthcare=community_care?

[Manda Andriatsiferana]

So, as far as I can understand:

   - health facility has doctor -> amenity=doctors + healthcare=*
   - health facility has no doctor -> amenity=health_post +
   healthcare=centre/nurse/community_health_worker

And this leaves no room for amenity=healthcare. Can't we just get a
rendering for amenity=health_post?

--
Dolly

On Sun, May 24, 2020 at 4:15 PM Paul Allen  wrote:

> On Sun, 24 May 2020 at 02:39, Claire Halleux 
> wrote:
>
>>
>> Agreed. Although, I'm not even sure if we should still need
>> amenity=healthcare or just go without it at some point.
>>
>
> There is a reason why it is still needed.
>
>>
>> Next: let's get them rendered on the map too.
>>
>
> And that's the reason amenity=healthcare is still needed.
>
> Ideally, OSM would put all its excrement in one sock, but we never seem to
> achieve that goal.
>
> --
> 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] any valid usage of admin_level=1 ?

[Marc M.]

Hello,

following a small thread on irc, I have review 20 usage of admin_level=1
all are mistakes, often by new mapper
for ex https://www.openstreetmap.org/way/779838275
is there a case of real use of admin_level=1?
wiki only said that UE isn't a admin_level=1
but don't list any valid usage of it
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
https://overpass-turbo.eu/s/Umf

are these all errors or is there an undocumented usecase ?

Regards,
Marc

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Jarek Piórkowski]

On Mon, 25 May 2020 at 07:22, Mateusz Konieczny via Tagging
 wrote:
> May 25, 2020, 11:06 by colin.sm...@xs4all.nl:
>> Is there a uniform definition of "motor_vehicle" in terms of its constituent 
>> vehicle classes? Do the constituent classes also have a uniform definition? 
>> A problematic example is "psv" where its status is not simply a function of 
>> the vehicle's construction or taxation class, but also of the use to which 
>> it is being put. If a taxi driver takes his taxi on holiday? A bus running 
>> empty back to the depot?
>
> And that is why psv is useful. Lets say that in given territory it applies to 
> bus on route with public
> and scheduled traffic and it does not apply to bus running service that is 
> not accessible to public.

Is meaning of psv=* territory dependent? I don't get that impression
from the wiki, and was under the impression it was to include taxis
worldwide. Please tell me if I had that wrong.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] any valid usage of admin_level=1 ?

[Colin Smale]

On 2020-05-25 14:58, Marc M. wrote:

> Hello,
> 
> following a small thread on irc, I have review 20 usage of admin_level=1
> all are mistakes, often by new mapper
> for ex https://www.openstreetmap.org/way/779838275
> is there a case of real use of admin_level=1?
> wiki only said that UE isn't a admin_level=1
> but don't list any valid usage of it
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
> https://overpass-turbo.eu/s/Umf
> 
> are these all errors or is there an undocumented usecase ?

I think the European Union is a good candidate for admin_level=1. It has
all the attributes of an administration, including elected
representatives and (in some cases) directly effective laws. It may be
unique in the world, but that doesn't change the duck-test outcome.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Mateusz Konieczny via Tagging]

May 25, 2020, 15:04 by ja...@piorkowski.ca:

> On Mon, 25 May 2020 at 07:22, Mateusz Konieczny via Tagging
>  wrote:
>
>> May 25, 2020, 11:06 by colin.sm...@xs4all.nl:
>>
>>> Is there a uniform definition of "motor_vehicle" in terms of its 
>>> constituent vehicle classes? Do the constituent classes also have a uniform 
>>> definition? A problematic example is "psv" where its status is not simply a 
>>> function of the vehicle's construction or taxation class, but also of the 
>>> use to which it is being put. If a taxi driver takes his taxi on holiday? A 
>>> bus running empty back to the depot?
>>>
>>
>> And that is why psv is useful. Lets say that in given territory it applies 
>> to bus on route with public
>> and scheduled traffic and it does not apply to bus running service that is 
>> not accessible to public.
>>
>
> Is meaning of psv=* territory dependent? I don't get that impression
> from the wiki, and was under the impression it was to include taxis
> worldwide. Please tell me if I had that wrong.
>
I though that the point of that tag was that it follows local legislation.

So if I have signs "public services vehicles are allowed" or
"pojazdy transportu bublicznego" and government will change
what counts as "public service vehicle"
 (fox example - minimum number of seats / includes excludes horse-drawn
carriages, excludes taxi vehicles that are not passing pollution 
requirements...)
there is no need to retweak bizarrely complicated conditional restrictions.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding values healthcare=dispensary and healthcare=community_care?

[Mateusz Konieczny via Tagging]

May 25, 2020, 14:53 by privatemaj...@gmail.com:

> And this leaves no room for amenity=healthcare. Can't we just get a rendering 
> for amenity=health_post?
>
Depends on a renderer. Such discussions about features in specific renderers 
are offtopic here
(though "is it possible to render it at all" may be on topic).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] any valid usage of admin_level=1 ?

[Mateusz Konieczny via Tagging]

May 25, 2020, 15:27 by colin.sm...@xs4all.nl:

>
> On 2020-05-25 14:58, Marc M. wrote:
>
>
>> Hello,
>>
>>  following a small thread on irc, I have review 20 usage of admin_level=1
>>  all are mistakes, often by new mapper
>>  for ex >> https://www.openstreetmap.org/way/779838275
>>  is there a case of real use of admin_level=1?
>>  wiki only said that UE isn't a admin_level=1
>>  but don't list any valid usage of it
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
>> https://overpass-turbo.eu/s/Umf
>>
>>  are these all errors or is there an undocumented usecase ?
>>
> I think the European Union is a good candidate for admin_level=1. It has all 
> the attributes of an administration, including elected representatives and 
> (in some cases) directly effective laws. It may be unique in the world, but 
> that doesn't change the duck-test outcome.
>
I agree that European Union seems to be a sole viable candidate.

I don't get
"trans-national administration is not a super-national organization"
argument, EU clearly has administration, de facto (also de iure?) laws, 
elections and so on.

Though it is area where I am not confident at all, so I am not really proposing 
to do that
- just that I would not be surprised or opposed.

I fixed https://www.openstreetmap.org/way/779838275 as clearly bogus.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Warin:

> Local to me the 'Great North Walk' is signposted in many different ways.
>
> e.g.
> Post with directional arrows
> http://thegreatnorthwalk.com/wp-content/uploads/2016/10/ww_photo_Looking-into-Mulbinga-Street.jpg
> Some of these posts have no name plate so those may not be recognized by
> those unfamiliar.
>

With route signs, you often can't tell what it is from one post. One post
is never a route, you always need extra information. In Nederland, many
routes have exactly the same symbol without further information. They show
the names only when they cross each other. If you're lucky!

Signboard
> http://thegreatnorthwalk.com/wp-content/uploads/2016/10/ww_photo_GNW-sign-on-the-Lyrebird-Trail.jpg
>

Looks like the trails run together for a while?

There are signboards indicating ways to the Great North Walk ..
> unfortunately labeled 'Great North Walk' leaving off the 'To the' so
> leading to miss-tagging of these paths/tracks - they are 'approach'
> paths/tracks/roads.
>

 In the role proposal, such a "to the ..." sign found on one trail and
pointing to another trail, would indicate a "connection" role. Otherwise an
"approach" role could be assigned.

If it is a sign pointing out the way from a PT station, parking lot or
mountain cabin, I would probably consider it an approach belonging to the
route. If it's just a sign on the road pointing to the nearby trail,
probably not worth mapping. But that's up to the mapper who knows the
territory. And often I google what the operator says.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

在 2020年5月25日週一 16:12，Florian Lohoff  寫道：

>
> Hola,
>
> On Mon, May 25, 2020 at 08:52:21AM +0200, Colin Smale wrote:
> > 1. Live and let live - OSM has always been a broad church. It might not
> > be your hobby, but it is their's. The bar to actively deleting other
> > people's work should be set very high indeed.
>
> I subscribe to this aswell. As long as it does not collide with stuff
> in use we should be able to tolerate data of historic or special purpose
> most of us probably do not aim for.
>
> The broad scope of your subject must otherwise be answered with: "No"
>
> It IS Best Common Practice to follow the "On the ground" rule with only
> very few exceptions.
>
> And IMHO we cant lift that. OSM needs to have a common ground to discuss
> matters and sometimes reality is already pretty hard to agree on. If we
> now add stuff in history or in the minds of mappers we open a pretty
> difficult can of worms.
>
> So - To quote from Postels Law - On of the inventors of the Internet:
>
> "Be conservative in what you do, be liberal in what you accept from others"
>
> 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


Your email initially sound like you thinl they shouldn't be deleted but
then it sound like you think they shouldn't be kept?

>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] taxi included in psv? (was: Access tag abuse examples)

[Jarek Piórkowski]

On Mon, 25 May 2020 at 09:29, Mateusz Konieczny via Tagging
 wrote:
>> Is meaning of psv=* territory dependent? I don't get that impression
>> from the wiki, and was under the impression it was to include taxis
>> worldwide. Please tell me if I had that wrong.
>
> I though that the point of that tag was that it follows local legislation.
>
> So if I have signs "public services vehicles are allowed" or
> "pojazdy transportu bublicznego" and government will change
> what counts as "public service vehicle"
>  (fox example - minimum number of seats / includes excludes horse-drawn
> carriages, excludes taxi vehicles that are not passing pollution 
> requirements...)
> there is no need to retweak bizarrely complicated conditional restrictions.

Could we change the wiki then? Because that's now how I interpret the
indented list on https://wiki.openstreetmap.org/wiki/Key:access, where
taxi is under psv, and while bus has a disclaimer "acting as a public
service vehicle", taxi has no such disclaimer.

https://wiki.openstreetmap.org/wiki/Key:psv is also IMO unclear
whether or not it includes taxi - up top it says "vehicles used in a
passenger service (no matter how many seating positions they might
have)" and taxi below - with no mention of local laws. Only in the
"See also" section it includes taxi again saying "taxi, which may or
may not be considered public service vehicles depending on location"

I ask because in my local jurisdiction, unlike in the UK, public
transit bus exceptions do not usually apply to taxis, and based on my
understanding of the wiki pages I've been changing psv to bus in those
cases when I see it. Which is correct?

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] any valid usage of admin_level=1 ?

[Phake Nick]

在 2020年5月25日週一 21:39，Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> 寫道：

>
>
>
> May 25, 2020, 15:27 by colin.sm...@xs4all.nl:
>
> On 2020-05-25 14:58, Marc M. wrote:
>
> Hello,
>
> following a small thread on irc, I have review 20 usage of admin_level=1
> all are mistakes, often by new mapper
> for ex https://www.openstreetmap.org/way/779838275
> is there a case of real use of admin_level=1?
> wiki only said that UE isn't a admin_level=1
> but don't list any valid usage of it
>
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
> https://overpass-turbo.eu/s/Umf
>
> are these all errors or is there an undocumented usecase ?
>
> I think the European Union is a good candidate for admin_level=1. It has
> all the attributes of an administration, including elected representatives
> and (in some cases) directly effective laws. It may be unique in the world,
> but that doesn't change the duck-test outcome.
>
> I agree that European Union seems to be a sole viable candidate.
>
> I don't get
> "trans-national administration is not a super-national organization"
> argument, EU clearly has administration, de facto (also de iure?) laws,
> elections and so on.
>
> Though it is area where I am not confident at all, so I am not really
> proposing to do that
> - just that I would not be surprised or opposed.
>
> I fixed https://www.openstreetmap.org/way/779838275 as clearly bogus.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


It is in the OpenStreetMap wiki itself that EU is a
super-national.organization:
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative

What I'm thinking about is, does Realm of New Zealand
http://en.wikipedia.org/wiki/Realm_of_New_Zealand count? Those territories
in the realm seems to still have some sort of power over comprosing
territories despite proclaimed independence.
Likewise, what about Kingdom of Denmark (relation 9110211)? It is now being
tagged as an administrative boundary but with no admin_level.
And what about British Crown Dependencies (relation 9110397) and British
Overseas Territory (relation 3969434)? The British Crown Dependencies is
now tagged as boundary=historic which seems wrong to me as it's still
current. The British Overseas Territory is tagged as
boundary=administrative but with no admin_level key.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding values healthcare=dispensary and healthcare=community_care?

[Manda Andriatsiferana]

Wait, I was wrong, it should be:

   - health facility has doctor -> amenity=doctors + healthcare=*
   - health facility has no doctor but has nurse -> healthcare=nurse/centre
   - health facility has neither doctor nor nurse -> amenity=health_post +
   healthcare=community_health_worker

Depends on a renderer. Such discussions about features in specific
> renderers are offtopic here
> (though "is it possible to render it at all" may be on topic).
>
Alright, let's forget about the renderers.

Cheers
--
Dolly Andriatsiferana


On Mon, May 25, 2020 at 4:33 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> May 25, 2020, 14:53 by privatemaj...@gmail.com:
>
> And this leaves no room for amenity=healthcare. Can't we just get a
> rendering for amenity=health_post?
>
> Depends on a renderer. Such discussions about features in specific
> renderers are offtopic here
> (though "is it possible to render it at all" may be on topic).
> ___
> 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] Adding values healthcare=dispensary and healthcare=community_care?

[Enock Seth Nyamador]

>
> These places have a particular focus on deadly diseases affecting
> children, they include prevention, health promotion and curative
> activities. Since these don't even have a single nurse as staff, I would
> like to propose a separate value such as healthcare=community_care or
> community_care_site.


Thanks, Claire, for this, it's been a long discussion, In Ghana the above
could be the same as to as Community-Based Health Planning and Services
(CHPS) compound [1] where there could be a nurse or a volunteer.

`amenity=health_post` is the closest I can agree to so far.

1. https://www.ghanahealthservice.org/chps/category.php?chpscid=98

Am Mo., 25. Mai 2020 um 15:29 Uhr schrieb Manda Andriatsiferana <
privatemaj...@gmail.com>:

> Wait, I was wrong, it should be:
>
>- health facility has doctor -> amenity=doctors + healthcare=*
>- health facility has no doctor but has nurse ->
>healthcare=nurse/centre
>- health facility has neither doctor nor nurse ->
>amenity=health_post + healthcare=community_health_worker
>
> Depends on a renderer. Such discussions about features in specific
>> renderers are offtopic here
>> (though "is it possible to render it at all" may be on topic).
>>
> Alright, let's forget about the renderers.
>
> Cheers
> --
> Dolly Andriatsiferana
>
>
> On Mon, May 25, 2020 at 4:33 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> May 25, 2020, 14:53 by privatemaj...@gmail.com:
>>
>> And this leaves no room for amenity=healthcare. Can't we just get a
>> rendering for amenity=health_post?
>>
>> Depends on a renderer. Such discussions about features in specific
>> renderers are offtopic here
>> (though "is it possible to render it at all" may be on topic).
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
-Enock
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Tagging-fr] [Talk-ml] [Talk-sn] With leisure=common deprecated, Senegal & Mali need a replacement

[Rafael Avila Coya]

Hi, Marc:

What I say is that, following this thread it's not clear to many of us 
that we have to deprecate a tag with which we are quite happy, and that 
a more clear definition would suffice to go on using it. Like for 
example the defining characteristics suggested by Jean-Marc Liotier today:


"The defining characteristics are: being open to public, not designated 
for a specific purpose, not landscaped (or that would be a park), not a 
marketplace (in West Africa, marketplaces are regulated and occur almost 
only at designated locations), not a pitch (when a couple pairs of 
goalposts are planted at extremities, the pitchness sometimes takes 
precedence and a few such locations are rightfully mapped as soccer 
pitches - but usually playing ball is just one of the uses of such places)".


So yes: I dispute that *statement*, as it doesn't reflect the geo object 
we are talking about. We are talking about the object that Jean-Marc 
(and others) are pointing and trying to give a good definition.


Cheers,

Rafael.

O 25/05/20 ás 14:15, Marc M. escribiu:

there's an *observation* that this tag has different meanings,
from a few blades of grass between 2 streets to a paved surface
for the big annual village party.
Do you dispute that *statement* ?
or do you want to deny it and repeat that only your meaning should
be taken into account ?
If you use it in your neighborhood, your own application may decide that
your meaning is the only common sense, but on a global level, this can't
succeed.

You seem to be talking about depreciation as if there was a voting
procedure, whereas in this case it's more like "these multiple meanings
make the tag unusable worldwide, fortunately there are less ambiguous
alternatives".

Le 25.05.20 à 00:19, Rafael Avila Coya a écrit :

Unless you demonstrate me that I am wrong, the tag leisure=common was
deprecated without any agreement with the community. So it's clearly not
a deprecated tag. Another thing is what you actually think about the tag
itself.

Cheers,

Rafael.

O 23/05/20 ás 20:49, Marc M. escribiu:

Agree on what?
That leisure=common needs a replacement ? Yes.
that replacement must be different from what needs to be replaced ?
it seems logical to me but some people think that replacing a
depreciated tag by itself will solve the problems that led to its
depreciation.


Le 22.05.20 à 15:46, Jean-Marc Liotier a écrit :

So, we are actually all in agreement, aren't we ?

Nous sommes donc tous d'accord, non ?


On 5/3/20 6:00 PM, severin.menard wrote:

Oui désolé, en effet je me suis trompé sur la clé !

Yes sorry, my mistake regarding the right key!



‐‐‐ Original Message ‐‐‐
Le dimanche 3 mai 2020 17:54, Pierre Béland via Talk-ml
 a écrit :


Fr

Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin,
je disais bien
   leisure=common

En

Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did
say...
   leisure=common
*/ /*


Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier
 a écrit :


So, this discussion gravitates towards using landuse=common for those
African urban freely accessible multipurpose open spaces, which I
fully support.

Implementing this change requires the following actions:

- Editing the leisure=common wiki page, in French and in English
(I'll do that)

- Reinstating the rendering of leisure=common in downstream
cartographic styles, would be even better if the color matched the
surface=* so that sandy surfaces don't appear green.

- Reinstating the rendering of leisure=common in JOSM's default style
(it recently changed to grey to mark deprecation). (I'll open a JOSM
ticket

- Altering QA rules (JOSM Validator and Osmose) so that the
leisure=common deprecation only applies to the United Kingdom of
Great Britain, where commons have a legal definition and
designation=common must be used for them. (I'll open a JOSM ticket
but if someone has prior experience interacting with the Osmose
people, that would be nice)


___
Tagging-fr mailing list
tagging...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging-fr


___
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] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

I took the liberty of revising the English translation in
https://wiki.openstreetmap.org/wiki/Key:sac_scale#Values to something
that I hope will be more helpful to English speakers. Some of the
phrases had obviously been machine-translated - the worst was most
likely 'single plainly climbing up to the second grade' which I
changed to 'Isolated easy climbing pitches up to UIAA grade 2'.

My German is not secure, and the original
(https://www.sac-cas.ch/fileadmin/Ausbildung_und_Wissen/Tourenplanung/Schwierigkeitsskala/Wanderskala-SAC.pdf)
is in Süddeutsch, verging on Schwyzertütsch, so please check me out on
it!

On Mon, May 25, 2020 at 7:42 AM Daniel Westergren  wrote:
> In Swedish we have basically "väg", which would translate to road or way, 
> while "stig" would translate to footpath/path/trail,
"Väg" is cognate to the English "way" - go back to the Tenth Century,
and they're the same word. Old Norse 'stígr,' 'wanderer,' appears not
to have survived into English, although one word that we use for the
concept clearly has Norse roots: 'vagabond.' 'Path' is of
West-Germanic origin, and has cognates in German, Dutch, Frisian,
Luxembourgeois, and (!) Finnish, but apparently not the Scandinavian
languages. "Track" came to English from Old French, but is almost
certainly a Norse borrowing. It's related to English words such as
'tread' and 'trek', Norwegian 'trå', and Swedish 'träda'.

> Sorry for having caused a very long, but certainly very interesting and 
> engaging thread on this never-ending topic. If it was discussed this way 12 
> (?) years ago, things would have been simpler. I understand the consensus as 
> although it would have been good, it's probably too late for a separate 
> highway tag for "trail" or whatever we call it and the only way forward is a 
> subtag like "highway=trail"? Although what we need then is a clear definition 
> of what it is and a way to handle all the cases when this subkey will not be 
> used.

Let me reiterate that the subkey that's needed is actually the one
that asserts 'this IS what one would expect of an urban or suburban
footway', rather than 'this is a relatively unimproved "natural"
trail'. We already have many attributes that would indicate that a
trail might be relatively unimproved (`surface=ground`; `incline=*`;
`wheelchair=no`; `width=*`, `smoothness=*`, `sac_scale=*` and so on).
The fundamental problem is that it is not safe to draw any conclusion
from the absence of such a tag. A mapper may have tagged a wilderness
trail as `highway=path` or `highway=footway` and simply not added the
other attributes.

The best way to help the data consumer will be to have a tagging
scheme that allows asserting 'this IS an urban/suburban/front-country
footpath' as well as 'this is a relatively unimproved trail'.  It's
true at the start that providing such a thing will leave most
`highway=path` features ambiguous, but it at least would open a way
forward for disambiguating them. `path=trail` will NOT accomplish that
goal, because it still leaves two choices: 'this is a trail', and
'this is unknown/ambiguous'.
-- 
73 de ke9tv/2, Kevin

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Florian Lohoff]

On Mon, May 25, 2020 at 10:12:34PM +0800, Phake Nick wrote:
> > So - To quote from Postels Law - On of the inventors of the Internet:
> >
> > "Be conservative in what you do, be liberal in what you accept from others"
> 
> Your email initially sound like you thinl they shouldn't be deleted but
> then it sound like you think they shouldn't be kept?

Its a matter of common sense. No we dont want to delete everything
immediatly - but for the sake of common ground for decisions we should
try to stick near the "On the ground" rule.

So be liberal but in case of dispute we need to stick with "On the
ground"

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[brad]

I think I agree with what Kevin is saying, but I confess I'm not sure 
what the problem is.   In my area, even looking at a nearby big city,  
most of the 'paths' are dirt trails.   There are some cycleways too.   
I'm not sure anyone maps sidewalks.
I think the fundamental problem is the original redundant 
footpath/cycleway/bridleway/path tags.   Trying to use the function 
instead of the physical characteristics.   It works for roads, but not 
for multiuser trails.


Someone asked what the hierarchy is.   Trails don't usually have a 
hierarchy like roads do.
Someone discussed purposely built paths vs naturally created trails.  
This doesn't work.  A lot of new trails are being built and they are 
designed and built by man and machine.  In steep terrain many old 
naturally created trails are eroded and rutted and closed down, or 
rerouted, or maintained by volunteers.


On 5/25/20 11:51 AM, Kevin Kenny wrote:


Let me reiterate that the subkey that's needed is actually the one
that asserts 'this IS what one would expect of an urban or suburban
footway', rather than 'this is a relatively unimproved "natural"
trail'. We already have many attributes that would indicate that a
trail might be relatively unimproved (`surface=ground`; `incline=*`;
`wheelchair=no`; `width=*`, `smoothness=*`, `sac_scale=*` and so on).
The fundamental problem is that it is not safe to draw any conclusion
from the absence of such a tag. A mapper may have tagged a wilderness
trail as `highway=path` or `highway=footway` and simply not added the
other attributes.

The best way to help the data consumer will be to have a tagging
scheme that allows asserting 'this IS an urban/suburban/front-country
footpath' as well as 'this is a relatively unimproved trail'.  It's
true at the start that providing such a thing will leave most
`highway=path` features ambiguous, but it at least would open a way
forward for disambiguating them. `path=trail` will NOT accomplish that
goal, because it still leaves two choices: 'this is a trail', and
'this is unknown/ambiguous'.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Change of wiki page Key:access

[Florian Lohoff]

On Mon, May 25, 2020 at 01:38:57PM +0200, Florimond Berthoux wrote:
> I have encounter this issue many times : reality vs traffic sign.
> No vehicle acces to the wood in Paris, except that cyclist go there and
> that normal.
> A living street sign on a transit road.
> Etc.
> 
> I would like to be able to tag separately the sign/law and the 'on the
> ground' reality.
> 
> For the default I'd say tag the reality if there almost no change to be
> blamed for violating the sign.
> 
> So for me the new tag would be
> motor_vehicle=no
> bicycle:dejure=no
> 
> Or if there is a little change to be blamed, bicycle:defacto=yes is nice
> too.
> 
> Could work also for highway :
> highway=tertiary
> highway:dejure=living_street

What would be your expectation which rules a router should honor? The
ones on the signs or the ones people actually do?

My expectation would be that an OSM based routing engine should never
send me where there is doubt i am allowed to go. It is okay for locals
to use it, but a someone from a different area/country i'd expect OSM
offering me a conflict free (in legal and physical terms) route based
on the tags it finds.

This is especially true for transit e.g. traversing something. This is
pretty inline with my in-car-nav (Mercedes E Class). It will not send
you where you are not allowed to go.
If there is some area with restrictions e.g. "Drop off zones at
Airports" or "Taxi spaces at railway stations" it will only send you
there at the final leg of your journey, and it'll warn you that you are
entering a restricted area before turning into it.

As a little anecdote what happens: I once tried to reach a campsite and
following my little Garmin on the bike. I ended in clear sight of the
campsite but with a River of ~40 meter width between me and the campsite. 
The reason was that the track i was on was actually the nearest point
on the routable network to the campsite. The divert was actually
something like 15km of which 10km were simply going back where i came
from. Somebody had tagged all the surrounding roads with access=private
so there was no other legal way of getting to the campsite by osm
tagging specs. This is one of the reasons why i am an opponent
of excessive and non justified access tagging. If we violate the on the
ground and verifyability of access restrictions there is no way to turn
back to a common ground. Reality will not matter anymore and we will
have tons of discussions with mappers about some invented or fictional
access restrictions.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Sarah Hoffmann]

On Sun, May 24, 2020 at 03:03:40PM -0400, Kevin Kenny wrote:
> On Sun, May 24, 2020 at 5:42 AM Sarah Hoffmann  wrote:
> > The SAC scale grades 1-3 are quite helpful. It's just the blue scales 4-6
> > which are not really applicable in OSM because very few routes of that
> > scale would fall under the highway=path classification (even under the
> > catch-all definition of OSM).
> 
> The first problem with the sac_scale is that it's not got anything at
> the low end. For trails in urban and suburban areas, we want to know,
> for instance, whether the trail might be accessible to the disabled or
> to small children. That's actually the single biggest problem here.

sac_scale is useful for what it was made for, namely hiking trails.
It was never meant to be used on urban paths. In fact, the presence
of the tag tells you that the path in question is not an urban path.
Complaining that it has no values for urban accessibility is like complaining
that all the values for the waterway key are unsuitable for highways.

> Without delving into a ton of auxiliary information, there's no
> difference between an urban footway and a wilderness trail!  For that
> reason, 'surface' and 'smoothness' and 'incline' and 'sac_scale' are
> all trolltags: they destroy fundamental expectations (at least to
> urbanites) of what a 'path' is. (Those false expectations are
> responsible for many outdoor accidents in my part of the world - I'm
> close enough to several large cities that we get many unprepared
> tourists.)

I highly doubt that somebody who doesn't think twice about using a
path in the mountains/outback without experience and gear will be deterred
by a suitability tag. The real problem with those people is the lack
of thinking not the lack of tagging.

That said, my favourite solution here would indeed be to add a new main
tag highway=trail and slowly retag the existing mountain paths starting
with the most dangerous/abused ones. They would disappear from the map for
a while until renderers and apps have adapted to the new schema.
I'd consider this actually a plus because only the data users that
are really interested in outdoors would adapt while for everybody else the
trails are just gone. And for the ones who do want to use them, we'd
send a very strong message: this is a different kind of highway,
you cannot just handle it like every other path. (I hope even the
Carto people finally get the message. The fact that they thought it
was a good idea to munge path and footway together is partially what
got us into this mess.)

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Joseph Eisenberg]

> The fact that they thought it was a good idea to munge path and footway
together is partially what got us into this mess

My understanding is that mappers were already using highway=footway and
highway=path in overlapping ways.

In Indonesia, there does not seem to be any consistency about whether the
unpaved foot path in the mountains, between remote villages, should be
tagged highway=footway or highway=path, for example. They are certainly not
designed for bicycles or horses (most of the bridges are only one narrow
log wide and there are many stiles and ladders to cross), but there is no
legal access prohibitions.

While most of this discussion has been considering recreational trails in
Western countries, it is important to remember than most unpaved footways,
paths and trails in the world are located in other countries. Remote areas
in Africa, Asia, Latin America and Oceania have extensive networks of
unpaved paths between remote villages in deserts, mountains and tropical
forests where there are no roads for 2-track motor vehicles.

– Joseph Eisenberg

On Mon, May 25, 2020 at 12:12 PM Sarah Hoffmann  wrote:

> On Sun, May 24, 2020 at 03:03:40PM -0400, Kevin Kenny wrote:
> > On Sun, May 24, 2020 at 5:42 AM Sarah Hoffmann  wrote:
> > > The SAC scale grades 1-3 are quite helpful. It's just the blue scales
> 4-6
> > > which are not really applicable in OSM because very few routes of that
> > > scale would fall under the highway=path classification (even under the
> > > catch-all definition of OSM).
> >
> > The first problem with the sac_scale is that it's not got anything at
> > the low end. For trails in urban and suburban areas, we want to know,
> > for instance, whether the trail might be accessible to the disabled or
> > to small children. That's actually the single biggest problem here.
>
> sac_scale is useful for what it was made for, namely hiking trails.
> It was never meant to be used on urban paths. In fact, the presence
> of the tag tells you that the path in question is not an urban path.
> Complaining that it has no values for urban accessibility is like
> complaining
> that all the values for the waterway key are unsuitable for highways.
>
> > Without delving into a ton of auxiliary information, there's no
> > difference between an urban footway and a wilderness trail!  For that
> > reason, 'surface' and 'smoothness' and 'incline' and 'sac_scale' are
> > all trolltags: they destroy fundamental expectations (at least to
> > urbanites) of what a 'path' is. (Those false expectations are
> > responsible for many outdoor accidents in my part of the world - I'm
> > close enough to several large cities that we get many unprepared
> > tourists.)
>
> I highly doubt that somebody who doesn't think twice about using a
> path in the mountains/outback without experience and gear will be deterred
> by a suitability tag. The real problem with those people is the lack
> of thinking not the lack of tagging.
>
> That said, my favourite solution here would indeed be to add a new main
> tag highway=trail and slowly retag the existing mountain paths starting
> with the most dangerous/abused ones. They would disappear from the map for
> a while until renderers and apps have adapted to the new schema.
> I'd consider this actually a plus because only the data users that
> are really interested in outdoors would adapt while for everybody else the
> trails are just gone. And for the ones who do want to use them, we'd
> send a very strong message: this is a different kind of highway,
> you cannot just handle it like every other path. (I hope even the
> Carto people finally get the message. The fact that they thought it
> was a good idea to munge path and footway together is partially what
> got us into this mess.)
>
> Sarah
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

在 2020年5月25日週一 19:35，Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> 寫道：

>
>
>
> May 25, 2020, 09:47 by dieterdre...@gmail.com:
>
>
>
> sent from a phone
>
> On 25. May 2020, at 08:54, Colin Smale  wrote:
>
> 1. Live and let live - OSM has always been a broad church. It might not be
> your hobby, but it is their's. The bar to actively deleting other people's
> work should be set very high indeed.
>
>
> +1
> I completely subscribe to this
>
> +1, but something that is 100% gone can be deleted.
>
> I have seen railway=abandoned mapped across open-pit mine that was there
> for 20 years.
>
> There was zero chance of mappers recreating it (as oldest aerials will
> show open pit mine),
> it was 100% gone (like embankments, railway station and dirt 20 m below).
>
> I deleted it.
>
> Something that is fully, completely and totally gone can be deleted. If
> there are buildings
> across former track of the railway and embankment is leveled then it can
> and should
> be deleted.
>
> If there are no traces whatsoever and you need old maps to map it then it
> is out of
> scope of OSM and deleting it improves OpenStreetMap.
>
> There was railway here:
>
> https://commons.wikimedia.org/wiki/File:National_Museum_in_Krakow-Main_Building,_1,_3Maja_Av,_Krakow,Poland.jpg
>
> There are no traces whatsoever. It is not mapped, should not be mapped and
> should be deleted if mapped.
>
> I have more doubts about cases where only earthworks remain (and are used
> for
> cycleway/road/path). You can plausibly guess that railway was there but it
> is just a
> guess and typically you need old maps to confirm that it was there.
>
> And in some cases such features look like former railway but that is not
> really true.
>
> But something that is totally gone should be gone from OpenStreetMap (with
> exceptions
> for objects marked as gone and temporarily not deleted to prevent
> incorrect remapping).
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


To add on it, I think something like
https://minkara.carview.co.jp/smart/userid/177050/blog/43940205/ should
still be included in the OpenStreetMap since some of their trace still
exists on the ground and that it's still more or less possible to locate
the alignment of the abandoned rail route.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Mateusz Konieczny via Tagging]

May 25, 2020, 20:34 by bradha...@fastmail.com:

> 'm not sure anyone maps sidewalks.
>
https://www.openstreetmap.org/#map=19/52.24167/21.01532&layers=N

https://taginfo.openstreetmap.org/tags/footway=sidewalk (only part of separately
mapped sidewalks has it)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Fernando Trebien]

If there is any detectable sign that there was a rail there one day,
surely it could be mapped - and especially so if the locals still
remember and/or refer to it.

If it has been completely removed, with other things built on top of
it, or the area completely remodeled so that there is no trace of the
former railway and no expectation of reconstruction, then it depends
on whether the former railway has significance in some other less
obvious way (e.g. being part of an administrative boundary). If not,
it should probably be removed, moved elsewhere [1], or changed into
something else (what's actually there now).

[1] 
https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_historic_events_and_historic_features

On Mon, May 25, 2020 at 2:06 AM Joseph Eisenberg
 wrote:
>
> This was originally sent to the Talk mailing list, but it is better if it is 
> discussed on the Tagging mailing list: 
> https://lists.openstreetmap.org/listinfo/tagging
>
> I agree that razed, completely demolished railways, where all traces of the 
> former track-bed have been removed, should be removed from OpenStreetMap.
>
> It is still considered acceptable to map abandoned railways, where the old 
> railway grade remains, even though the metal rails have been removed.
>
> However, note that there are some people who are very committed to mapping 
> historical and abandoned railways, so there may be resistance to removing 
> these features.
>
> See the long discussions about rendering railway=abandoned at 
> https://github.com/gravitystorm/openstreetmap-carto/pull/542 and 
> https://github.com/gravitystorm/openstreetmap-carto/issues/586 for example.
>
> Also see the previous discussion at 
> https://wiki.openstreetmap.org/wiki/Talk:Railways#Abandoned_railways_where_all_evidence_has_been_removed
>
> – Joseph Eisenberg
>
> On Sun, May 24, 2020 at 9:40 PM Jack Armstrong  wrote:
>>
>> Greetings.
>>
>>
>> Recently, a user mapped “razed” railways inside a construction zone (link 
>> below). These rails had been removed by our local mappers since they don’t 
>> exist anymore. Using the latest imagery (Maxar), you can see the rails have 
>> been completely removed from “Project 70”, a $1.2 billion Denver-area 
>> transportation corridor construction project.
>>
>>
>> I think this mapper has good intentions, but what is the point of mapping 
>> something that does not exist? Doesn’t this clearly contradict the OSM Good 
>> Practice wiki in regards the sections, “Verifiability”, “Map what's on the 
>> ground” and “Don't map historic events and historic features”? The last 
>> section states, "Do not map objects if they do not exist currently."
>>
>>
>> Should we tag (invisible) razed sidewalks? Should we leave (invisible) 
>> destroyed buildings in place, tag them as razed and then create new 
>> buildings on top of them?
>>
>>
>> https://www.openstreetmap.org/edit#map=19/39.78016/-104.94562
>>
>>
>>
>>
>> ___
>> talk mailing list
>> t...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
Fernando Trebien

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Mateusz Konieczny via Tagging]

May 25, 2020, 23:50 by fernando.treb...@gmail.com:

> then it depends
> on whether the former railway has significance in some other less
> obvious way (e.g. being part of an administrative boundary)
>
This is going too far. Glaciers left clear marks in many countries, but
mapping glaciers of last glacial maximum[1] is out of scope of OSM.

If sole trace of railway is that administrative boundary matches its course,
then it should be deleted.

[1] https://en.wikipedia.org/wiki/Last_Glacial_Maximum

>
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[brad]

I meant in my area

On 5/25/20 3:47 PM, Mateusz Konieczny via Tagging wrote:




May 25, 2020, 20:34 by bradha...@fastmail.com:

'm not sure anyone maps sidewalks.

https://www.openstreetmap.org/#map=19/52.24167/21.01532&layers=N

https://taginfo.openstreetmap.org/tags/footway=sidewalk (only part of 
separately

mapped sidewalks has 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] [OSM-talk] Should we map things that do not exist?

[Jack Armstrong]

I agree with Mateusz Konieczny. If there is some vestige of the object remaining, then mapping it in some way seems reasonable. But, if the railway, building, highway, etc., are completely removed and there are absolutely no visible remains of what was once there, it can be removed.I don't see the need to map something that does not actually exist.- Jack Armstrongchachafish-Original Message-
From: Mateusz Konieczny via Tagging 
Sent: May 25, 2020 4:15 PM
To: "Tag discussion,
 strategy and related tools" 
Cc: Mateusz Konieczny 
Subject: Re: [Tagging] [OSM-talk] Should we map things that do not exist?


  

  
  
May 25, 2020, 23:50 by fernando.treb...@gmail.com:then it dependson whether the former railway has significance in some other lessobvious way (e.g. being part of an administrative boundary)This is going too far. Glaciers left clear marks in many countries, butmapping glaciers of last glacial maximum[1] is out of scope of OSM.If sole trace of railway is that administrative boundary matches its course,then it should be deleted.[1] https://en.wikipedia.org/wiki/Last_Glacial_Maximum  



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Alan Mackie]

Has this edit war stabilised?

Apparently it has been blocking coastline updates across the whole world
for *months *now.

https://osmdata.openstreetmap.de/data/land-polygons.html
https://github.com/fossgis/osmdata/issues/7


On Mon, 13 Jan 2020 at 11:40, Christoph Hormann  wrote:

> On Monday 13 January 2020, Frederik Ramm wrote:
> >
> > According to Wikipedia, the International Hydrographic Organization
> > defines the eastern boundary of the Río de la Plata as "a line
> > joining Punta del Este, Uruguay and Cabo San Antonio, Argentina",
> > which is what has been the case in OSM until now:
>
> That is a straw man argument that has been floated already at the very
> beginning when a riverbank polygon was first created for that (which
> was later than when the Río de la Plata was originally mapped by the
> way - just to clarify that).
>
> The IHO specifies an (obviously subjective and non-verifiable) set of
> limits of *oceans and seas*.  If anyone wants to use this as an
> argument that would make the Río de la Plata a marginal sea of the
> Atlantic Ocean and therefore to be placed outside the coastline.  So
> using the IHO as a source (in lieu of the verifiable geography in a
> Wikipedia-like fashion so to speak) kind of defeats the basic argument
> for the Río de la Plata to not be a maritime waterbody.
>
> > This current representation in OSM leads to a few strange situations
> > especially in toolchains/map styles that use different colours for
> > inland water and oceans, or that draw sea depths, or just highlight
> > the coastline. Buenos Aires, according to OSM, is currently not a
> > coastal city.
>
> The main reason why the current mapping is vigorously maintained by some
> local mappers is political in nature.  Argentina and Uruguay want to
> claim this area as internal waters (and the administrative boundaries
> are mapped accordingly) but not every other nation accepts this claim.
> Presenting the Río de la Plata as a non-maritime waterbody in as many
> maps and data sets as possible would support such claim.
>
> My own solution as a data user to this has been to simply maintain a
> coastline cheatfile which marks this as a special case and moves the
> Río de la Plata polygon into the ocean polygon data.  This is
> unfortunate but way simpler than trying to fight against a widespread
> politically motivated conviction.  See also:
>
> https://wiki.openstreetmap.org/wiki/Tag:maritime=yes
>
> > I'm not so clear about how to interpret the wiki page myself when it
> > comes to river mouths. There's a clarifying proposal here
> > https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River
> >_transit_placement but this is still at the proposal stage.
>
> The IMO logical approach to placing the closing segment of the coastline
> at a river mouth according to the spirit of the OpenStreetMap project
> is to place it where for the verifiable view of humans the maritime
> domain ends and the riverine domain starts.  This is largely an
> ecological question.  Coastline and riverbanks are physical geography
> features so their position is to be defined by physically observable
> characteristics rather than politically defined limits.  Like so often
> (for example in case of the line between scrubland and woodland) this
> is often not a clearly visible sharp line but a transit.  There are
> however clearly observable limits to the extent of this transit.  The
> proposal cited tries to specify those.
>
> Back when i drafted the proposal there was very little interest in the
> subject except by those who were opposed to it for political reasons.
> Therefore i did not pursue it further.  But anyone is welcome to take
> it up again.
>
> --
> 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] oneway=yes on motorways

[Paul Johnson]

On Sun, May 24, 2020, 18:51 Shawn K. Quinn  wrote:

> On 5/24/20 15:26, Volker Schmidt wrote:
> > I just noticed an apparent contradiction regarding the use of the oneway
> > tag between the wiki pages key:oneway
> >  and motorway
> >  .
> > The former states:
> > "Some tags (such as junction
> > =roundabout
> > , highway
> > =motorway
> >  and others)
> > imply oneway=yes and therefore the oneway tag is optional,
> > the latter states:
> > "These ways should all point direction of travel and be tagged with
> > oneway =yes"
> > 
> >
> > What is the agreed standard, if any?
>
> It can't hurt to specify oneway=yes. I have noticed that the JOSM style
> that shows lane counts and lane use will sometimes not show ways
> properly if oneway=yes isn't there, but that's probably a bug in the
> style more than an indictment of implying oneway=yes.
>

I'm on the side of "team tag explicitly" on this.  If anything, it gives
validators more to work with if you start doing something weird.

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Arne Johannessen]

Mateusz Konieczny via Tagging  wrote:
> May 25, 2020, 02:45 by a...@thaw.de:
>> 
>> [access=private driveways implicitly permitting delivieries to destination?]
>> 
>> Not all deliveries are actively requested, and the delivery person can't 
>> know if you requested it or not.
> 
> Good point. Maybe it can be argued that there is implicit permission for 
> delivery services?
> My uncle has farm, with clearly private yard (it is unsigned).
> 
> Postman or package delivery would be welcomed there and - even if package 
> would not be requested, but random person driving to
> front of his house would not be and AFAIK would violate law.

I think what you're describing is access=destination, not =private.


> [...]
> 
>> FWIW, I'm less happy with the current state of the access=private page. But 
>> I'm not sure if consensus exists to clarify it.
> What is wrong and how you want to change it?

It does not specifiy precisely what the tag value =private means. It also 
doesn't make a clear enough distinction between private ownership and private 
access (by using the term "private" colloqiually and by showing a picture of 
what looks like an ownership=private situation).


To stick with driveways, consider yesterday's posts by Colin Smale and Florian 
Lohoff on this topic on OSM-talk. [1][2] It seems to me that to a degree, both 
points of view can be backed up by the current text on the access=private wiki 
page. [3] That suggests the wiki page doesn't describe the tag in a 
particularly useful way.

I think the earlier example of a nuclear power plant was a useful one. We 
clearly need a tag value that means: Absolutely no access unless by explicit 
prior permission. Currently, =private seems to fill that need. That would mean 
the definition of =private cannot include any kind of "implicit" permissions. 
Those would need another tag value. Implicit permissions should probably be 
treated by routers similarly to =destination, so perhaps =destination (or 
=permissive) could simply be used in such cases?

A side-effect of requiring explicit permissions for =private is that =no and 
=private are almost exact synonyms. (The =private wiki page already points this 
out.) Therefore, an alternative might be to give the meaning "explicit prior 
permission required" to =no, while allowing implicit permissions for =private. 
This would seem like a major change though, and I'm not sure I'd agree with it.


I think the =private wiki page could be improved by clarifying that =private 
really does require _explicit_ prior permission. The "Facilities" section 
already mentions "a closed group of users", which implies just that, but 
evidently this isn't very clear.

Additionally, the language generally could use a bit of cleanup, the relation 
to alternatives like =destination should be mentioned, and the picture should 
be like a "no trespassing" sign (ideally something that works for most 
jurisdictions).

(I might take a swing at this if I find the time.)


[1] <549c82c01046d2acd1ad8d41ca408...@xs4all.nl>
https://lists.openstreetmap.org/pipermail/talk/2020-May/084774.html
[2] <20200525181730.6rbnfqyygw3yt...@pax.zz.de>
https://lists.openstreetmap.org/pipermail/talk/2020-May/084791.html
[3] 
https://wiki.openstreetmap.org/w/index.php?title=Tag:access%3Dprivate&oldid=1986562

-- 
Arne Johannessen



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging