Re: [Tagging] amenity=music_school vs amenity=college?

[Mateusz Konieczny]

5 Sep 2019, 07:18 by joseph.eisenb...@gmail.com:

> Are music schools a type of amenity=college or should they be their own tags?
>
At this moment there is no documented way of tagging that
something is a music school using amenity=college.

Is it simply missing from Wiki or is there no scheme for that?

In current situation given choice of formless amenity=college
and amenity=music_school second is strictly preferable.

Also, note that at least in Poland "music school" is typically NOT
"further education" - children go both to a normal school and 
to a musical school that operates also like normal school (though 
with lessons and homework focused strictly on music).

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

Re: [Tagging] amenity=music_school vs amenity=college?

[Warin]

On 5/9/19 3:18 pm, Joseph Eisenberg wrote:

Are music schools a type of amenity=college or should they be their own tags?



Education should have its own key.

See 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative

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

[Tagging] amenity=music_school vs amenity=college?

[Joseph Eisenberg]

Are music schools a type of amenity=college or should they be their own tags?

The tag amenity=college is used for any "institution of further
education" which isn't a university; this includes junior colleges and
adult education facilities in the USA, though the term "further
education" is British English and doesn't always translate directly.

It's not clear if this includes music schools. There are separate tags
for amenity=driving_school and amenity=language_school, which are
included in the Map Features list.

Should  amenity=music_school be in map features?

Here are the wiki pages to review:

https://wiki.openstreetmap.org/wiki/Tag:amenity=language_school - used
1700 times

https://wiki.openstreetmap.org/wiki/Tag:amenity=music_school - used 3000 times

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcollege - used 50,000 times

(amenity=driving_school is used 16,000 times)

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

Re: [Tagging] Add amenity=childcare to Map Features?

[Joseph Eisenberg]

There were 5 positive comments in favor, and none in opposition, so
I've added amenity=childcare to map features as discussed. See
https://wiki.openstreetmap.org/wiki/Template:Map_Features:amenity

I've added to the description: "Describes a place where children are
looked after **which is not an amenity=kindergarten**" and added the
text to the page:

This tag is used for places where children are looked after,
**including a nursery or daycare which takes care of small children
who are too young for amenity=kindergarten or preschool, and
after-school childcare facilities.**

Hopefully that helps clarify why this tag is used instead of
amenity=kindergarten in countries where a "kindergarten" or preschool
does not accept school-aged or nursery-age children.

- Joseph

On 8/25/19, Joseph Eisenberg  wrote:
> The tag amenity=childcare is fairly popular (used 17,000 times), and
> it's supported by the iD editor and the Openstreetmap-carto rendering.
>
> Should this tag be added to the wiki page Map Features?
>
> The original proposal wasn't supported because some people thought
> that amenity=kindergarten should be used for all types of childcare,
> not only preschools/kindergartens. This seems to be the common
> situatoin in Germany, but may not match they types of daycare /
> childcare / preschool facilities available in other countries. For
> example, in the USA most preschools do not take older children after
> school; such after-school care is usually provided by separate
> programs.
>
> Wiki page:  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dchildcare
> Proposal:  https://wiki.openstreetmap.org/wiki/Proposed_features/childcare
> Compare to Kindergarten:
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkindergarten
>

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

Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Warin]

On 5/9/19 2:42 am, Richard Fairhurst wrote:

Peter Elderson wrote:

The network values identify transport mode and scope of routes, and
these "dimensions" also apply to node networks. We do not want to
add another dimension (configuration type) to the network=*
values of routes.

Instead, we are thnking about just adding a tag to identify segment
routes as parts of a node network. The nodes themselves do not need
this, since they ARE nodes and have a xxn_ref tag.

In short, we are thinking to simply add the tag network_type=
node_network (or network:type=node_network) to the node2node
network routes.

I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)

You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

So I'd suggest that instead of network_type=, you add route_type= .


'Type' does not add information. If the key is only to have one value .. why 
not use the proposed value as the key?

node_network=yes/no ?


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

Re: [Tagging] Feature Proposal - RFC - Campsite properties

[Joseph Eisenberg]

Sven,

Thank you for your comments, I appreciate having your involvement in
this proposal.

>> 2)  Deprecate bbq=* (use barbecue_grill=* instead).
>
> Well, in practice according to taginfo there are zero campsites featuring an
> additional bbq or barbecue_grill tag.

Mainly this is used for picnic sites. It's not a common tag;
barbecue_grill=* is about equally used but also still rare. But it
might be useful for specifying all the features at a
tourism=camp_pitch, in addition to picnic sites and the like. The
reason for choosing barbecue_grill=* instead of bbq=* is that bbq
could imply permission to user your own grill, rather than the
presence of a grill which is permanently installed at the feature.

> Well if you are about additional tags I would strongly recomend adding
> another one which is already supported in http://opencampingmap.org
> In Germany there are a lot of campsites which rent pitches on a seasonal or
> even yearly base. People often use them as a kind of weekend home.
> We call them "Dauercamper" which is likely called "permanent campers" in
> english.
> As this is quite common here and there are even sites for permanent
> residents _only_ I invented a tag called permanent_camping=yes/no/only

That's an interesting idea. I don't know much about this concept
myself, so it would be better if this were kept separate. Is it like
renting a summer cabin, or more like having a permanent spot in a
mobile home park (eg for fixed caravans)?

I see it's already been used 50 times. Maybe you can make a proposal
or a wiki page to document it?
https://wiki.openstreetmap.org/w/index.php?title=Key:permanent_camping=edit

Thank you for your help,

-Joseph Eisenberg

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

Re: [Tagging] Feature Proposal - RFC - Campsite properties

[Joseph Eisenberg]

Correct. And often there is a greywater drain at each individual camp
pitch, but only one sanitary_dump_station where caravans and RVs can empty
their sewage tank.

On Thu, Sep 5, 2019 at 9:15 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 4. Sep 2019, at 21:00, Sven Geggus 
> wrote:
> >
> > Is there a difference between a greywater_drain and a
> > sanitary_dump_station?
>
>
> greywater is wastewater without feces, e.g. from sinks and showers, while
> I would guess that a sanitary dump station is for sewage.
>
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hill figures

[Martin Koppenhoefer]

sent from a phone

> On 4. Sep 2019, at 23:45, Graeme Fitzpatrick  wrote:
> 
> But would that really apply to these, as most of them only range in age from 
> <100 to 200-300 years old?


as long as you find a suitable value ;-)

In general the civilization tags aim more at older sites while for more recent 
features, start_date may be more appropriate.


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

Re: [Tagging] Feature Proposal - RFC - Campsite properties

[Martin Koppenhoefer]

sent from a phone

> On 4. Sep 2019, at 21:00, Sven Geggus  wrote:
> 
> Is there a difference between a greywater_drain and a
> sanitary_dump_station?


greywater is wastewater without feces, e.g. from sinks and showers, while I 
would guess that a sanitary dump station is for sewage.


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

Re: [Tagging] Hill figures

[Graeme Fitzpatrick]

On Wed, 4 Sep 2019 at 18:54, Martin Koppenhoefer 
wrote:

> It could make sense in this context to mention the tag
> historic:civilization
> which is about the culture that created a feature.
>
> https://wiki.openstreetmap.org/wiki/Key:historic:civilization
>

But would that really apply to these, as most of them only range in age
from <100 to 200-300 years old?

Thanks

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

Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Peter Elderson]

Richard Fairhurst :

> Peter Elderson wrote:
> > The network values identify transport mode and scope of routes, and
> > these "dimensions" also apply to node networks. We do not want to
> > add another dimension (configuration type) to the network=*
> > values of routes.
> >
> > Instead, we are thnking about just adding a tag to identify segment
> > routes as parts of a node network. The nodes themselves do not need
> > this, since they ARE nodes and have a xxn_ref tag.
> >
> > In short, we are thinking to simply add the tag network_type=
> > node_network (or network:type=node_network) to the node2node
> > network routes.
>
> I have a strong interest in this proposal. :) [1]
>
> If I understand you rightly, a route like
> https://www.openstreetmap.org/relation/1844941 would get an extra
> network_type=node_network tag. Nothing else would change. (Correct me if
> I'm
> wrong.)
>

You are correct.


> You say "we don't want to add another dimension" but you are effectively
> doing that; you're just doing it by adding a new tag rather than adding a
> value. That's not _necessarily_ a problem but it would be better done in an
> extensible way that might be useful for other tagging scenarios, rather
> than
> special-casing this one scenario.
>

We do want to add a new aspect: network configuration. We just do not want
to add this new aspect into the network tag, because it already has two
aspects in it: transport mode and geographical scope. Therefore we decided
to just add the new information independent of the other two.

This simply allows us (Nederland, Belgium and Germany) to return to the use
of rXn as it was intended. We then no longer need the exception that rXn is
a node network in these countries only, and a regular regional route (chain
of ways) in the rest of the world.


> We currently have the "network=ncn|rcn|lcn" tag which broadly identifies
> the
> _importance_ of the route.
>

More specific, it gives the transport mode and the geographical scope,
including icn for international cycling routes. Same for hiking, and usage
for other transport modes (horseriding, canoe, skating) is emerging, and so
are regular (chain of ways) routes and node networks including special node
network planners.


> What we do not have is a tag to identify the _character_ and _purpose_ of
> the route. All bicycle routes (except MTB) get lumped together as a generic
> route=bicycle. This is increasingly a problem as routes are devised and
> signposted for performance cycling, bikepacking, and so on. For example,
> there are two new performance cycling routes in Wales which I'd like to map
> (https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would
> be
> misleading if tagged in the same way as other NCN/RCN/LCN routes in
> Britain.
>
> You're proposing a tag called "network_type", but it's a tag for the route,
> and what you're using it to describe is the character and purpose of the
> route. (The network is already mapped in the network super-relation.)
>

That is not the idea. Maybe I wasn't clear. The idea is to add the network
setup or configuration in a clear and unmistakeable way.

You bring up an interesting point: the superrelation. The superrelations
are containers of a mix of route relations and nodes but they don't give
how these elements are connected. This is the case for both regular routes
(think long distance, international, variants) and node network
superrelations. So data users using routes would have to determine
membership of a superrelation, then analyse the superrelation to find out
whether a route is part of a node network, or part of another type of
superrelation.
At this time, local walking node networks are merging with provincial
walking node networks and regional walking node networks into one big
national walking node network with connections and branches to Belgian and
German walking node networks. The orginal relatively small local node
networks already were very difficult to maintain and to use, but on the
cureent larger scale the are unmanageabe and unusable.

Adding the information as a tag to the individual network routes solves
this problem as well.


> So I'd suggest that instead of network_type=, you add route_type= .
>
> This would achieve the same purpose; be semantically more appropriate; and
> be extensible to other routes where "route=bicycle" alone does not
> adequately capture the character and purpose of the route.
>
>
I disagree. The information is that the route is part of a particular
network setup. This does not alter the route itself. It's not about the
character of the route, it's about the configuration of the network it's a
part of.


> Richard
> cycle.travel
>
>
> [1] I believe cycle.travel is the only OSM-based router that includes
> nodes
> in its turn-by-turn instructions, e.g.
> https://cycle.travel/map?from=51.0623,2.8582=51.0913,2.8531 .
> cycle.travel also has a few localised rules for rendering in the
> Netherlands
> and Belgium to cope 

Re: [Tagging] Feature Proposal - RFC - Campsite properties

[Sven Geggus]

Hello,

first of all, as the author of http://opencampingmap.org I
basically support any approach to streamline the tagging of campsites!

However, I would also like to point out, that the main problem we currently
have with campsite mapping in OSM ist not _inaccurate_ tagging but _no_
additional tagging at all!

About one third of the sites do not even have a name and another third have
a name tag as the only additional one.  This will add up to about 60% of
sites whith incomplete tagging.

Just have a look at the "Campsites with incomplete tagging" site I made up
using Osmoscope:
http://osmoscope.openstreetmap.de/#map=4/4.85321/40.84314=https://camping.openstreetmap.de/osmoscope/incomplete-campsites.json

Joseph Eisenberg  wrote:

> It's been a week since the RFC for this proposal focused on campsites
> and related tourism features. It which would:

Well not all Users of Openstreetmap-data are regular followers of the
tagging list.  Don't you think, that known users of stuff you are discussing
should be included in such a discussion?

I just came about this one reading weekly OSM news and I think that I am
certainly one of the known users in case of this stuff.

> It which would:
> 
> 1) Deprecate booking=* (use reservation=* instead)

I am usually not a friend of such discussions.  I just tend to enforce
streamlining tagging by using one tag but not another.  "booking" is
currently not honored in Open Camping Map because it is barely used, so yes,
if you like to get rid of it in a somewhat official way I would not object.

Another (IMO) mess which comes to mind ist this regard ist the "contact:"
prefix bullshit which made me include a tag-mapping feature anyway.

So with the current code handling booking in the same way as reservation
would be easy to do.

> 2)  Deprecate bbq=* (use barbecue_grill=* instead).

Well, in practice according to taginfo there are zero campsites featuring an
additional bbq or barbecue_grill tag.

What we often have is an amenity=bbq feature somewhere on the site, which
I honor on my map.

So frankly I do not care about this one that much as it is currently not in use
anyway and thus not supported.

> 3) Create new wiki pages:
> amenity=greywater_drain
> amenity=power_supply
> amenity=bear_box
> waste_disposal=yes/no
> bear_box=yes/no
> greywater_drain=yes/no

I do not currently support these.

However, it might be a good idea to treat an amenity=power_supply on the
premises the same as power_supply=yes on the site-object.

Is there a difference between a greywater_drain and a
sanitary_dump_station?

> scout=yes/no

In the context of my map I currently treat scout=yes the same as
"group_only=yes".  These are sites for groups (likely private) after all,
regardless of the type of group.

> And add new values to these pages:
> Key:parking - add parking=yes/no
> Key:capacity=* - capacity:tents/caravans/static_caravans would be mentioned

Yeah well probably capacity should be specified more clearly. In practice
this is even more complicated as some people think of capacity in terms of
people rather than tents or caravans. I currently prefer using maxtents as
this is more well-defined.

> That's a lot of changes. So if anyone dislikes one of these changes,
> please say so, so that I can separate it out into it's own proposal.

Well if you are about additional tags I would strongly recomend adding
another one which is already supported in http://opencampingmap.org

In Germany there are a lot of campsites which rent pitches on a seasonal or
even yearly base. People often use them as a kind of weekend home.

We call them "Dauercamper" which is likely called "permanent campers" in
english.

As this is quite common here and there are even sites for permanent
residents _only_ I invented a tag called permanent_camping=yes/no/only

Regards

Sven

P.S.: You may also have a look at my Open Camping Map Announcement
http://blog.gegg.us/2019/01/announcing-open-camping-map/

-- 
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say." (Edward Snowden)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Peter Elderson]

I think it's the best AND the easiest solution.
Network configuration type is currently not tagged. Nederland, Belgium and
Germany decided to use rcn exclusively for the cycle node networks. Later
they copied that to rwn for the emerging walking node networks.
We now want to correct that, but we also want a clear difference between
the network condfigurations. Then renderers and other data users can make
the distinction.

We have considered using another network=* value. But the transport mode is
still in there, as is the geographical scope. So you would need extra
values for all combinations of mode, scope and config. If yet another
network config type emerges, you will need more network values. Every data
user has to decode the values to know what's going on. While what we want
is just to indicate that this particular rcn route is part of a node
network.

This is true for all transport modes (now and future) and for all
geographical scopes, now and future.

So we came to the solution that it is by far the most effective and at the
same time the easiest solution to just add the information that a route is
part of a node network in a separate tag. The bonus is that other network
systems can be accommodated as well. E.g. some regions and some nature
parks in Nederland have a "colour choice network", where you can follow a
(self-planned) sequence of signposted coloured routes.

The extra bonus of this solution is that currently tagged node network
routes need no retagging, just addition of the information that they are
part of a node network. This allows renderers and other data users to
refine the display or handling of the existing rXn routes.

We thought of network_type as a key. This is not a new key, it has some
non-conflicting usage. We could introduce a new key as a namespaced
variant: network:type=*.

If this is still confusing: feel free to suggest better names and values to
indicate that a route belongs to a network system of the node variety.

Fr gr Peter Elderson


Op wo 4 sep. 2019 om 18:33 schreef s8evq :

> Why don't you continue to use network=* ? Invent a new value for network=
> instead of introducing a new, but confusing tag called "network_type".
>
> I understand that using network_type would be easier. You just add the tag
> to the already tagged node networks that are currently using network=rwn.
>
> But is introducing a new tag "network_type=" really the best solution? Or
> is it the easiest solution?
>
> On Wed, 4 Sep 2019 16:44:58 +0200, Peter Elderson 
> wrote:
>
> >
> >
> > Mvg Peter Elderson
> >
> > > Op 4 sep. 2019 om 16:30 heeft Simon Poole  het
> volgende geschreven:
> > >
> > >
> > >> Am 04.09.2019 um 15:59 schrieb Peter Elderson:
> > >> Thanks for the illustrations!
> > >>
> > >> network=* gives geographical scope (local, regional, national,
> > >> international) and transport mode (bicycle, foot, canoe, horse, mtb,
> > >> ski, skate, )
> > > You know what I'm going to point out.
> > >
> > > The redundant coding of transportation kind in the the geographical
> > > scope was a mistake, but is a done deed for cycling and hiking. BUT
> > > there is no need to propagate repeating the mistake for every other
> > > transportation mode, lets just stick with local, regional, national and
> > > international these (historically I suspect that the values came from
> > > direct tagging on ways,  lcn=yes and similar).
> >
> > I agree with your point. Had I been around, I probably would have voted
> not to mix scope and mode in one tag. At the same time, the proposed tag
> for network configuration type does not change this, nor does it propagate
> it. So I would like to keep this a separate issue, and just talk about how
> to separate regular routes from node networks.
> >
> > > ___
> > > Tagging mailing list
> > > Tagging@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Hill Figures

[Peter Neale via Tagging]

Date: Wed, 4 Sep 2019 10:14:17 +0200 (CEST)
From: Mateusz Konieczny 
To: "Tag discussion, strategy and related tools"
    
Cc: "Tag discussion, strategy and related tools"
    
Subject: Re: [Tagging] Hill figures
Message-ID: 
Content-Type: text/plain; charset="utf-8"

4 Sep 2019, 09:42 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 4. Sep 2019, at 09:08, Volker Schmidt  wrote:
>>
>> man_made=geoglyph (usage >700 in taginfo)
>> Seems to be a reasonable tagging
>>
>
>
> +1
>
+1, I added it to some of linked example that were missing it
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/tagging/attachments/20190904/eb9735bc/attachment-0001.html>

+1   I have added the man-made=geoglyph tag to the Bulford Kiwi 
(https://www.openstreetmap.org/node/3119018826)
Peter  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Richard Fairhurst]

Peter Elderson wrote:
> The network values identify transport mode and scope of routes, and 
> these "dimensions" also apply to node networks. We do not want to 
> add another dimension (configuration type) to the network=*  
> values of routes.
> 
> Instead, we are thnking about just adding a tag to identify segment 
> routes as parts of a node network. The nodes themselves do not need 
> this, since they ARE nodes and have a xxn_ref tag.
> 
> In short, we are thinking to simply add the tag network_type=
> node_network (or network:type=node_network) to the node2node 
> network routes.

I have a strong interest in this proposal. :) [1]

If I understand you rightly, a route like
https://www.openstreetmap.org/relation/1844941 would get an extra
network_type=node_network tag. Nothing else would change. (Correct me if I'm
wrong.)

You say "we don't want to add another dimension" but you are effectively
doing that; you're just doing it by adding a new tag rather than adding a
value. That's not _necessarily_ a problem but it would be better done in an
extensible way that might be useful for other tagging scenarios, rather than
special-casing this one scenario.

We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the
_importance_ of the route.

What we do not have is a tag to identify the _character_ and _purpose_ of
the route. All bicycle routes (except MTB) get lumped together as a generic
route=bicycle. This is increasingly a problem as routes are devised and
signposted for performance cycling, bikepacking, and so on. For example,
there are two new performance cycling routes in Wales which I'd like to map
(https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be
misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain.

You're proposing a tag called "network_type", but it's a tag for the route,
and what you're using it to describe is the character and purpose of the
route. (The network is already mapped in the network super-relation.)

So I'd suggest that instead of network_type=, you add route_type= .

This would achieve the same purpose; be semantically more appropriate; and
be extensible to other routes where "route=bicycle" alone does not
adequately capture the character and purpose of the route.

Richard
cycle.travel


[1] I believe cycle.travel is the only OSM-based router that includes nodes
in its turn-by-turn instructions, e.g.
https://cycle.travel/map?from=51.0623,2.8582=51.0913,2.8531 .
cycle.travel also has a few localised rules for rendering in the Netherlands
and Belgium to cope with the sheer density of the node network.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[s8evq]

Why don't you continue to use network=* ? Invent a new value for network= 
instead of introducing a new, but confusing tag called "network_type".

I understand that using network_type would be easier. You just add the tag to 
the already tagged node networks that are currently using network=rwn.

But is introducing a new tag "network_type=" really the best solution? Or is it 
the easiest solution?

On Wed, 4 Sep 2019 16:44:58 +0200, Peter Elderson  wrote:

> 
> 
> Mvg Peter Elderson
> 
> > Op 4 sep. 2019 om 16:30 heeft Simon Poole  het volgende 
> > geschreven:
> > 
> > 
> >> Am 04.09.2019 um 15:59 schrieb Peter Elderson:
> >> Thanks for the illustrations!
> >> 
> >> network=* gives geographical scope (local, regional, national,
> >> international) and transport mode (bicycle, foot, canoe, horse, mtb,
> >> ski, skate, )
> > You know what I'm going to point out.
> > 
> > The redundant coding of transportation kind in the the geographical
> > scope was a mistake, but is a done deed for cycling and hiking. BUT
> > there is no need to propagate repeating the mistake for every other
> > transportation mode, lets just stick with local, regional, national and
> > international these (historically I suspect that the values came from
> > direct tagging on ways,  lcn=yes and similar).
> 
> I agree with your point. Had I been around, I probably would have voted not 
> to mix scope and mode in one tag. At the same time, the proposed tag for 
> network configuration type does not change this, nor does it propagate it. So 
> I would like to keep this a separate issue, and just talk about how to 
> separate regular routes from node networks.
> 
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Peter Elderson]

Mvg Peter Elderson

> Op 4 sep. 2019 om 16:30 heeft Simon Poole  het volgende 
> geschreven:
> 
> 
>> Am 04.09.2019 um 15:59 schrieb Peter Elderson:
>> Thanks for the illustrations!
>> 
>> network=* gives geographical scope (local, regional, national,
>> international) and transport mode (bicycle, foot, canoe, horse, mtb,
>> ski, skate, )
> You know what I'm going to point out.
> 
> The redundant coding of transportation kind in the the geographical
> scope was a mistake, but is a done deed for cycling and hiking. BUT
> there is no need to propagate repeating the mistake for every other
> transportation mode, lets just stick with local, regional, national and
> international these (historically I suspect that the values came from
> direct tagging on ways,  lcn=yes and similar).

I agree with your point. Had I been around, I probably would have voted not to 
mix scope and mode in one tag. At the same time, the proposed tag for network 
configuration type does not change this, nor does it propagate it. So I would 
like to keep this a separate issue, and just talk about how to separate regular 
routes from node networks.

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

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

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Simon Poole]

Am 04.09.2019 um 15:59 schrieb Peter Elderson:
> Thanks for the illustrations!
>
> network=* gives geographical scope (local, regional, national,
> international) and transport mode (bicycle, foot, canoe, horse, mtb,
> ski, skate, )
You know what I'm going to point out.

The redundant coding of transportation kind in the the geographical
scope was a mistake, but is a done deed for cycling and hiking. BUT
there is no need to propagate repeating the mistake for every other
transportation mode, lets just stick with local, regional, national and
international these (historically I suspect that the values came from
direct tagging on ways,  lcn=yes and similar).




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

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[Peter Elderson]

Thanks for the illustrations!

network=* gives geographical scope (local, regional, national,
international) and transport mode (bicycle, foot, canoe, horse, mtb, ski,
skate, )

network_type gives network configuration type (chain of ways;
node_network=network of nodes)

The network configuration type is applicable to all geographical scopes and
all transport modes. By adding this as a separate tag the network=rXn tag
is free again for regional routes. This applies in Nederland, Belgium and
Germany. In other countries the tag network_type creates the option to
register node networks in OSM if they are implemented, without reserving a
mode/scope network=XXn tag which may be already in use for regular routes
(conform the wiki's about routes).

Please feel free to offer other solutions!

Fr gr Peter Elderson


Op wo 4 sep. 2019 om 14:53 schreef s8evq :

> On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson 
> wrote:
> > Tagging of regular cycle route relations is route=lcn for local routes,
> rcn
> > for regional routes, ncn for national routes, icn for international
> routes.
>
>
> You probably mean network=lcn instead of route=lcn
>
>
> > I hope this clears things up?  In terms of proposal, we propose one extra
> > value "node_network" for the key "network_type".
> > Nothing is changed, nothing is removed. So we think zero impact on the
> > current base. It's up to renderers and other data users to make use of
> the
> > extra tag.
>
> So hiking node network would still be tagged with network=rwn, but you
> would just add network_type=node_network.
>
> If yes, then I find this a bad proposal. What is the difference between
> network=* and network_type=*
>
> Do not choose network_type because it's the most easy solution!!!
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[s8evq]

On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson  wrote:
> Tagging of regular cycle route relations is route=lcn for local routes, rcn
> for regional routes, ncn for national routes, icn for international routes.


You probably mean network=lcn instead of route=lcn


> I hope this clears things up?  In terms of proposal, we propose one extra
> value "node_network" for the key "network_type".
> Nothing is changed, nothing is removed. So we think zero impact on the
> current base. It's up to renderers and other data users to make use of the
> extra tag.

So hiking node network would still be tagged with network=rwn, but you would 
just add network_type=node_network.

If yes, then I find this a bad proposal. What is the difference between 
network=* and network_type=*

Do not choose network_type because it's the most easy solution!!!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

[s8evq]

On Tue, 3 Sep 2019 16:56:49 +0200, Peter Elderson  wrote:

> Op zo 1 sep. 2019 om 12:35 schreef Andy Townsend :
> 
> > On 29/08/2019 15:52, Peter Elderson wrote:
> > > LS
> > > With the arrival of cycling node networks, the Dutch, German and
> > > Belgian mappers decided to claim (hijack)  the network value rcn for
> > > those node networks. This exception was copied with the claim of
> > > network=rwn for the walking node networks.
> >
> > Would it be possible to try and describe in a bit more detail what has
> > happened, without using judgmental terms such as "hijack"?  I'd start
> > with a link helping people understand what a "cycling node network" is.
> >
> 
> Sure. A node network consists of numbered nodes (signs) with short routes
> between pairs of adjacent nodes. Eg nodes 10, 35 and 22 with routes 20-35,
> 10-22 and 22-35, and then each of these nodes has other connections to
> other nodes. 


Some pictures might make it more clear for somebody who has never heard of this 
system:

This is an example of a node: (in this case node 55) 
https://pretwerk.nl/wp-content/uploads/knopen-lopen.jpg

From that point, individual waymarks indicate the route to one of the 
connecting nodes (54, 91 and 56 in this case). 
So, along the road between two nodes, you will then find this kind of signs:
https://www.anwb.nl/binaries/content/gallery/anwb/portal/wandelen/wandelroutes/soorten-routes/knooppuntroutes/wandelknooppunt_kvp.jpg


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

Re: [Tagging] Hill figures

[Martin Koppenhoefer]

It could make sense in this context to mention the tag
historic:civilization
which is about the culture that created a feature.

https://wiki.openstreetmap.org/wiki/Key:historic:civilization

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

Re: [Tagging] Hill figures

[Mateusz Konieczny]

4 Sep 2019, 09:42 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 4. Sep 2019, at 09:08, Volker Schmidt  wrote:
>>
>> man_made=geoglyph (usage >700 in taginfo)
>> Seems to be a reasonable tagging
>>
>
>
> +1
>
+1, I added it to some of linked example that were missing it
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hill figures

[Martin Koppenhoefer]

sent from a phone

> On 4. Sep 2019, at 09:08, Volker Schmidt  wrote:
> 
> man_made=geoglyph (usage >700 in taginfo)
> Seems to be a reasonable tagging


+1

Cheers Martin 

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

Re: [Tagging] Hill figures

[Volker Schmidt]

The Uffington White Horse
https://www.openstreetmap.org/relation/1618450
is mapped as man_made=geoglyph (usage >700 in taginfo)
Seems to be a reasonable tagging




Virus-free.
www.avast.com

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

On Wed, 4 Sep 2019 at 01:16, Warin <61sundow...@gmail.com> wrote:

> Not all of them are on hills.
>
> Marree Man https://en.wikipedia.org/wiki/Marree_Man
>
> Possibly  artwork=geoglyph ???
>
> https://en.wikipedia.org/wiki/Geoglyph
>
>
> On 4/9/19 8:49 am, Andy Mabbett wrote:
>
> In the UK, hill figures include:
>
> * The Cerne Abbas Giant [1], [2], [3]
> * The Fovant badges [4], [5], [6]
> * RNLI Dunkirk Memorial at Margate [7], [8]
> * Osmington White Horse [9], [10], [11]]
>
> and others exist elsewhere [12]. As can be seen from my examples,
> these usually significant landmarks are often not rendered on the map
> - the exception in my examples is at Osmington.
>
> Some cover areas (e.g. Osmington, which is why it renders), some are
> "tramlines" (Cerne Abbas), and some (the RNLI memorial) are single
> lines.
>
> I propose we tag the latter two types as, say, artwork=hill_figure,
> and request that such items be rendered at higher zoom levels.
>
> What alternative approaches are available?
>
> [1] https://en.wikipedia.org/wiki/Cerne_Abbas_Giant
>
> [2] 
> https://www.openstreetmap.org/?mlat=50.813611=-2.474722=15#map=15/50.8136/-2.4747
>
> [3] https://www.openstreetmap.org/way/675453847 (part)
>
> [4] https://en.wikipedia.org/wiki/Fovant_Badges
>
> [5] 
> https://www.openstreetmap.org/?mlat=51.0534=-1.9783=15#map=15/51.0534/-1.9783
>
> [6] https://www.openstreetmap.org/way/136177861 (single badge)
>
> [7] https://www.openstreetmap.org/#map=19/51.38736/1.37969
>
> [8] https://www.openstreetmap.org/relation/9995162
>
> [9] https://en.wikipedia.org/wiki/Osmington_White_Horse
>
> [10] 
> https://www.openstreetmap.org/?mlat=50.65741=-2.40438=11#map=17/50.65741/-2.40438
>
> [11] https://www.openstreetmap.org/way/120665846#map=18/50.65788/-2.40433
>
> [12] https://en.wikipedia.org/wiki/Hill_figure
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging