Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Andrew Harvey]

Agreed with Phake, any boundary that's used for administrative purposes
could be included, that's what I understand from
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative. That
doesn't mean that each area needs to have it's own legal entity and
administrator, nor need to be able to set laws, rules, codes etc. just that
the boundary itself is used for some administrative purposes.

On Thu, 14 May 2020 at 07:29, Joseph Eisenberg 
wrote:

> At the US talk mailing list and
> https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level there
> has been discussion about whether or not certain features should be tagged
> as administrative boundaries in the States of Connecticut, Rhode Island and
> Massachusetts.
>
> While all these States have counties, in some cases most of the government
> functions have been lost, and are handled by the State (admin_level=4) or
> Town/City government (admin_level=8).
>
> However, I have the impression that in some countries, certain local
> administrative boundaries do not actually have "home rule", or the ability
> to make their own laws, for example in French-infuenced areas?
>
> What is the minimum qualification for a boundary to be considered a
> boundary=administrative with an admin_level in your country?
>
> -- 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] Meaning of "administrative" in boundary=administrative, in your country?

[Phake Nick]

In South Korea/Japan/China/Taiwan, the minimal administrative level are
usually equivalent of neighborhoods, and have little to no substantial
administrative functions.
For example, https://www.openstreetmap.org/relation/3987250 this is
admin_level=9 in South Korea, https://www.openstreetmap.org/relation/5830985
this is admin_level=10 in Japan,
https://www.openstreetmap.org/relation/9230465 this is admin_level=9 in
Taiwan, https://www.openstreermap.org/relation/8248082 this is
admin_level=10 in China.
Note that admin_level=10 also exists in Taiwan but only a few of them have
already been mapped as a relation in OSM.

在 2020年5月14日週四 05:29，Joseph Eisenberg  寫道：

> At the US talk mailing list and
> https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level there
> has been discussion about whether or not certain features should be tagged
> as administrative boundaries in the States of Connecticut, Rhode Island and
> Massachusetts.
>
> While all these States have counties, in some cases most of the government
> functions have been lost, and are handled by the State (admin_level=4) or
> Town/City government (admin_level=8).
>
> However, I have the impression that in some countries, certain local
> administrative boundaries do not actually have "home rule", or the ability
> to make their own laws, for example in French-infuenced areas?
>
> What is the minimum qualification for a boundary to be considered a
> boundary=administrative with an admin_level in your country?
>
> -- 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

[Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Joseph Eisenberg]

At the US talk mailing list and
https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level there
has been discussion about whether or not certain features should be tagged
as administrative boundaries in the States of Connecticut, Rhode Island and
Massachusetts.

While all these States have counties, in some cases most of the government
functions have been lost, and are handled by the State (admin_level=4) or
Town/City government (admin_level=8).

However, I have the impression that in some countries, certain local
administrative boundaries do not actually have "home rule", or the ability
to make their own laws, for example in French-infuenced areas?

What is the minimum qualification for a boundary to be considered a
boundary=administrative with an admin_level in your country?

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

Re: [Tagging] relations & paths

[Mateusz Konieczny via Tagging]

Obvious, route relations covers the same type of 
objects that has different names, even in English.

In other languages you will get even more names,
but I will not start using
type=szlak_turystyczny relation type.

May 13, 2020, 18:17 by bradha...@fastmail.com:

> It isn't a route, except in OSM, it's just a trail.
>  
>  
> On 5/13/20 9:09 AM, Paul Johnson wrote:
>
>>
>>
>> On Wed, May 13, 2020 at 9:23AM brad <>> bradha...@fastmail.com>> 
>> >wrote:
>>
>>> It isn't part of a route,it's the whole route.
>>>
>>
>>  I think that's a difference without a distinction inthis case.  
>> Data consumers still need to know the route isthere. 
>>
>> ___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] relations & paths

[Yves]

I prefer a single member route relation than a way with type=route, 
route=whatever. The later lead to much more uncertainty in the tags meaning.
Yves 

Le 13 mai 2020 18:17:37 GMT+02:00, brad  a écrit :
>It isn't a route, except in OSM, it's just a trail.
>
>On 5/13/20 9:09 AM, Paul Johnson wrote:
>>
>>
>> On Wed, May 13, 2020 at 9:23 AM brad > > wrote:
>>
>> It isn't part of a route, it's the whole route.
>>
>>
>>  I think that's a difference without a distinction in this case. 
>Data 
>> consumers still need to know the route is there.
>>
>> ___
>> 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] relations & paths

[Mateusz Konieczny via Tagging]

May 13, 2020, 17:43 by jm...@gmx.com:

>
> On 5/13/2020 10:12 AM, Paul Johnson wrote:
>
>
>>
>> We've had relations for over a decade now, IIRC.  It'stime to 
>> stop treating this basic primitive asentity-non-grata.  If tools 
>> >> still>>  can't deal withthis, this is on the tools and their 
>> developers now.
>>
> Sure. Regarding the original question -- in what circumstances are
> single-member walking/hiking/biking route relations a good mapping
> practice -- what would be your answer?
>
Always.
(a) for consistency.
(b) because in case of splitting this single  way it will be not result in 
problems with relation
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[brad]

It isn't a route, except in OSM, it's just a trail.

On 5/13/20 9:09 AM, Paul Johnson wrote:



On Wed, May 13, 2020 at 9:23 AM brad > wrote:


It isn't part of a route, it's the whole route.


 I think that's a difference without a distinction in this case.  Data 
consumers still need to know the route is there.


___
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 - Dog hazard

[Volker Schmidt]

The hazard tagging has a problem, when you try to apply it.

A dog hazard is a hazard to people by dogs or is a hazard to dogs by
mountain lions or whatever.
In a different thread we are discussing dooring hazard.
I would love to see a more general approach to hazard and danger tagging,
but do not have a proposal ready.
I would love to be able to tag hazards of all kinds mainly for cyclists in
my case.
One of them was hazard by free running dog packs.



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, 13 May 2020 at 13:14, ael  wrote:

> On Tue, May 12, 2020 at 03:26:07PM -0700, Tod Fitch wrote:
> > dog=yes|no|leashed already exists for a totally different semantic
> (letting dog owners know if their pet is allowed).
> >
> > If this goes forward I would prefer reversing thing and make it
> hazard=dog. That would also allow other types of hazards to be mapped.
> >
> > Checking taginfo it seems hazard=* [1] is in use. Why not go with it?
>
> You beat me to it. The existing hazard tag is the obvious choice which I
> use quite often. Although it does not seem to be well supported by data
> consumers. I have used it in Cornwall to flag open mine shafts, and in
> one case to warn of dangerous (illegal) dogs on a right of way through a
> farmyard.
>
> 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] relations & paths

[Paul Johnson]

On Wed, May 13, 2020 at 10:43 AM Jmapb  wrote:

> On 5/13/2020 10:12 AM, Paul Johnson wrote:
>
>
> We've had relations for over a decade now, IIRC.  It's time to stop
> treating this basic primitive as entity-non-grata.  If tools *still* can't
> deal with this, this is on the tools and their developers now.
>
> Sure. Regarding the original question -- in what circumstances are
> single-member walking/hiking/biking route relations a good mapping practice
> -- what would be your answer?
>

Is it part of a network?  Is it signed as part of a network?  OK 166 was a
single member relation until I did lane tagging on it and had to split that
way a couple times.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Jmapb]

On 5/13/2020 10:12 AM, Paul Johnson wrote:



We've had relations for over a decade now, IIRC.  It's time to stop
treating this basic primitive as entity-non-grata.  If tools
/still/ can't deal with this, this is on the tools and their
developers now.


Sure. Regarding the original question -- in what circumstances are
single-member walking/hiking/biking route relations a good mapping
practice -- what would be your answer?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Paul Johnson]

On Wed, May 13, 2020 at 9:23 AM brad  wrote:

> It isn't part of a route, it's the whole route.


 I think that's a difference without a distinction in this case.  Data
consumers still need to know the route is there.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[brad]

It isn't part of a route, it's the whole route.

On 5/12/20 8:58 PM, Paul Johnson wrote:
On Tue, May 12, 2020 at 9:37 PM brad > wrote:


OK, but it seems redundant to me.   A trail/path get tagged as a
path.
There's a trailhead and a sign, it gets a tagged with a name.  
Why does
it need to be a route also?


Same reason all 0.11 miles of I 95 in Washington DC is part of a 
route.  It's part of a route.


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



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

Re: [Tagging] relations & paths

[Paul Johnson]

On Wed, May 13, 2020 at 9:06 AM Jmapb  wrote:

> On 5/12/2020 10:58 PM, Paul Johnson wrote:
>
> On Tue, May 12, 2020 at 9:37 PM brad  wrote:
>
>> OK, but it seems redundant to me.   A trail/path get tagged as a path.
>> There's a trailhead and a sign, it gets a tagged with a name.   Why does
>> it need to be a route also?
>>
>
> Same reason all 0.11 miles of I 95 in Washington DC is part of a route.
> It's part of a route.
>
> Yes but that's *part* of a route, a route relation with many other
> members. Brad's asking about single-member route relations.
>
And so is that 50-51 segment in the Dutch cycle network. Even if it's  a
particularly short one.

> Finally there's the issue of software and rendering support. Waymarked
> Trails, as Kevin mentioned, only supports route relations. I believe other
> hiking map renderers work similarly. Of course this is not how OSM is
> "supposed" to work -- structuring data for a particular renderer or
> software -- but nonetheless it is a factor in how people map.
>
We've had relations for over a decade now, IIRC.  It's time to stop
treating this basic primitive as entity-non-grata.  If tools *still* can't
deal with this, this is on the tools and their developers now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Jmapb]

On 5/12/2020 10:58 PM, Paul Johnson wrote:

On Tue, May 12, 2020 at 9:37 PM brad mailto:bradha...@fastmail.com>> wrote:

OK, but it seems redundant to me.   A trail/path get tagged as a
path.
There's a trailhead and a sign, it gets a tagged with a name.  
Why does
it need to be a route also?


Same reason all 0.11 miles of I 95 in Washington DC is part of a
route.  It's part of a route.


Yes but that's *part* of a route, a route relation with many other
members. Brad's asking about single-member route relations.

My understanding, still evolving, is that tagging conventions originally
developed for long-distance walking routes -- thing like osmc:symbol,
colour, distance, network -- are sometimes applicable to shorter trails,
including those that are only a single highway=path/footway. Mappers
reading the wiki page for osmc:symbol will be told that this tag is only
to be used with route relations. Some mappers who want to add a symbol
to a single-highway trail might tag osmc:symbol directly on the highway
anyway (Taginfo shows 2924 instances of this) and some might create a
single-member route relation.

Another thing to consider -- for vehicle roads we have a many-tiered
hierarchy from motorway down to track, which assists in routing and
rendering. Paths and footways have no such hierarchy, so adding them to
a relation along with the relation-specific tags is one technique
mappers have used to call out trails of greater importance.

Finally there's the issue of software and rendering support. Waymarked
Trails, as Kevin mentioned, only supports route relations. I believe
other hiking map renderers work similarly. Of course this is not how OSM
is "supposed" to work -- structuring data for a particular renderer or
software -- but nonetheless it is a factor in how people map.

Jason

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

Re: [Tagging] Feature Proposal - RFC - Dog hazard

[ael]

On Tue, May 12, 2020 at 03:26:07PM -0700, Tod Fitch wrote:
> dog=yes|no|leashed already exists for a totally different semantic (letting 
> dog owners know if their pet is allowed).
> 
> If this goes forward I would prefer reversing thing and make it hazard=dog. 
> That would also allow other types of hazards to be mapped.
> 
> Checking taginfo it seems hazard=* [1] is in use. Why not go with it?

You beat me to it. The existing hazard tag is the obvious choice which I
use quite often. Although it does not seem to be well supported by data
consumers. I have used it in Cornwall to flag open mine shafts, and in
one case to warn of dangerous (illegal) dogs on a right of way through a
farmyard.

ael


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

[Tagging] Tag:amenity=refugee_site

[Manon Viou]

 
 
  
   
Hello everyone,
   
   

   
   
The OSM tag proposal Amenity=refugee_site has been validated with 31 votes for and 2 votes against.
   
   

   
   
(
https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2)
   
   

   
   
I would like to thank you for your participation and the shared advices to find the most suitable solution.
   
   

   
   
We will create the wiki page for this new tag very soon.
   
   

   
   
We also plan to update and complete the more general wiki page presenting refugee camp mapping on OSM (
https://wiki.openstreetmap.org/wiki/Refugee_Camp_Mapping). If you are interested in this project, let me know!
   
   

   
   
Best regards,
   
   

   
   
Manon
   
  
  
   
   
 


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

Re: [Tagging] Quality and the Openstreetmap value chain

[Jez Nicholson]

You might need to divide 'data user' into:

'data processors (?)' - those that extract, manipulate, and combine data
ready to use/display.

'database users' - those that use/display the information with minimal
preprocessing.

Recent discussions appear to be a mismatch between the needs of the 2.

On Wed, 13 May 2020, 09:43 Shawn K. Quinn,  wrote:

> On 5/13/20 03:31, Colin Smale wrote:
> > These are two distinct user types or personas, each with their own list
> > of requirements/expectations. Let's recognise that and treat them
> > separately in this discussion.
>
> Okay, "map user" and "data user" then? Anything to get "consumer" out of
> the lexicon... it doesn't belong.
>
> --
> Shawn K. Quinn 
> http://www.rantroulette.com
> http://www.skqrecordquest.com
>
> ___
> 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] Quality and the Openstreetmap value chain

[Shawn K. Quinn]

On 5/13/20 03:31, Colin Smale wrote:
> These are two distinct user types or personas, each with their own list
> of requirements/expectations. Let's recognise that and treat them
> separately in this discussion.
  
Okay, "map user" and "data user" then? Anything to get "consumer" out of
the lexicon... it doesn't belong.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-13 10:20, Shawn K. Quinn wrote:

> On 5/12/20 17:18, Graeme Fitzpatrick wrote: 
> 
>> I'd really like somebody to come up with simple definitions of
>> 
>> mappers,
>> 
>> data consumers / customers,
>> 
>> users?
> 
> I'd consider "user" and "data consumer" to be the same thing (but would
> prefer "user" or even "data user" in light of the objection to
> "consumer" used in this context at
> ).
> 
> A "user" is someone who makes use of the data generated by the
> OpenStreetMap project including its volunteers.

I think we should be clear about the distinction between consumers of
the DATA (via APIs and downloads, in XML and PBF formats) and users of
the RESULTS of processing that data (map renderings, other applications
etc). Officially (unless it's changed) OSM is about the DATA, but many
issues with the data don't surface until someone sees the results. These
are two distinct user types or personas, each with their own list of
requirements/expectations. Let's recognise that and treat them
separately in this discussion.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Quality and the Openstreetmap value chain

[Shawn K. Quinn]

On 5/12/20 17:18, Graeme Fitzpatrick wrote:
> I'd really like somebody to come up with simple definitions of
> 
> mappers,
> 
> data consumers / customers,
> 
> users?

I'd consider "user" and "data consumer" to be the same thing (but would
prefer "user" or even "data user" in light of the objection to
"consumer" used in this context at
).

A "user" is someone who makes use of the data generated by the
OpenStreetMap project including its volunteers. A "mapper" (or "editor")
would be someone who creates and/or updates the data for the project.
One easily can be both at different times, in fact, I would hope most if
not all mappers "eat their own dog food" and use OSM data as much as
possible in preference to e.g. Google or Bing maps.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Quality and the Openstreetmap value chain

[Marc M.]

Hello,

Le 13.05.20 à 00:18, Graeme Fitzpatrick a écrit :
> I'd really like somebody to come up with simple definitions of

let's try :)

> mappers,

someone who adds data into osm

> data consumers / customers,

someone who get data from osm

> I map, & I then also "use" OSMand for navigation purposes, so what am I?

a mappers and a user of OSMand (by using OSMAnd, you don't use the data
directly, if a tag changes, it is osmand that has to change and not you
as an osmand user).

Regards,
Marc

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月13日週三 12:24，Mark Wagner  寫道：

> On Tue, 12 May 2020 23:53:52 +0800
> Phake Nick  wrote:
>
> > Except capacity is only one of many differences between common taxi
> > and motorcycle taxi.
>
> Are there any differences that can't be explained by the fact that a
> motorcycle taxi uses a motorcycle to carry the passengers?
>
> For example, in the United States, we've got what are called "airport
> shuttles".  These look and act a lot like a taxi, but either the start
> point or the end point of the journey must be the airport -- you can't
> use them as general point-to-point transportation like you could a taxi
>

It can be explained, but not necessarily intuitively so. Like you can
attribute the fare different and access restriction to them using
motorcycle vehicles, but these are not properties of a motorcycle itself.

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

Re: [Tagging] Quality and the Openstreetmap value chain

[Graeme Fitzpatrick]

On Wed, 13 May 2020 at 11:13, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Dirt road may be highway=trunk if it is the main road of national road
> system.
> Muddy road, not even surface=compacted is highway=primary in some region.
>
> is it mistagged as highway=track? Then it is a data issue, not rendering
> issue.
>

Currently tagged as highway=secondary, so I'll have a look at upping them
to primary / trunk, thanks.

> Same, same with the (OSM) villages / hamlets / remote dwellings that this
> road serves. A single building out in the middle of nowhere, in the OSM
> universe, is too small & insignificant to be noticed, *but* that pub,
> with attached service (gas) station, general store & camping ground, is
> also the major point of civilisation for that 1000 k's!, so how important
> is it in real life to those people who are travelling through that area?
> Extremely!
>
> This is sadly a hard to resolve rendering issue. Special purpose rendering
> of OSM data may be helpful for such areas.
>

The concept of mapping "villages" as towns to make them show has been
discussed several times on the Aussie list! Yes, yes, it's tagging for the
renderer, but sometimes that seems to be the only way around things?

Thanks

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