Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Hidde Wieringa
I just wanted to add `Relation:site` [1] to this topic. This is not an 
approved tag (proposal [2], seems abandoned), but it is used to group 
'things' together which cannot be grouped simply with a multipolygon. I 
do not expect this relation type to be rendered 'correctly' (whatever 
that may mean without a good proposal and definition) in many renderers, 
but the information will exist in OSM in a structured way for future 
renderers.


Example query for South-Sweden: https://overpass-turbo.eu/s/119b

Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Relation:site
[2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site


On 13-12-2020 11:28, Anders Torger wrote:

Here's a real example of how this naming scheme ends up looking:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png 



I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to 
keep track of all parts big and small if there is no relation, so I 
added it as a help for the mapper. I set type=natural (to indicate 
that it's a natural object) and natural=wetland (to indicate what type 
of natural it is, without having to deduce from its members) and name 
on that relation. Nothing official, but at least easy to filter out 
and find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble 
into the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just 
don't exist. It's the usual problem: mappers won't map things that 
don't show up on any renderer (or displays horribly like this), and 
renderers won't implement functions for things that aren't mapped. The 
OSM way is that mappers should take the lead and renderers will 
eventually follow (maybe). I think that process works really poorly 
today (the main reason being that OSM is just too large and diverse 
now for the original processes to work, in global scope every feature 
becomes just a tiny special interest not worth considering). That we 
still lack these cartography features 14 years into the project is 
witness to that. We need a render engine to take the lead, and more 
well-defined standard of how to arrange the data. I've got 4 - 5 
different suggestions of how to put a name on this wetland. Imagine if 
all those naming schemes gets used, what a mess to implement a 
renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:

I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
 See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is a topic of some confusion among mappers.
For example, I don't believe Carto rendering is perfectly predictable
without first knowing "size of all overlapping polygons."  This can
make "accurate" (or pleasing) natural tagging challenging or
unpredictable in some circumstances.  I believe at least some of what
is rendered has to do with the size (and order entered?) of
overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable
tagging t

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Hidde Wieringa
You indicate that you are aware that relations aren't categories [1]. So 
indeed, grouping elements which share a certain tag is not useful. 
Finding nodes/ways that contain a certain tag is easily possible with 
specialized query tooling such as the Overpass API [2]. Data duplication 
across elements is not really an issue, and simplicity and correctness 
are more important.


What do you mean by the "primary relation for a way"? Relations group 
elements together, and as such a way can be part of any number of 
relations. The way itself does not 'know' if it is part of any relations 
(although you could query such information).


I want to mention tools like Osm2pgsql [3] which transforms the OSM data 
model to a relational database such as PostgreSQL. You can import vast 
amounts of data and pre-process it for your specific application if you 
so desire. You could group certain information together if your use-case 
would benefit from it.


Kind regards,
/Hidde Wieringa/

[1] 
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

[2] https://dev.overpass-api.de/overpass-doc/en/
[3] https://osm2pgsql.org/



On 16-11-2020 18:13, Seth Deegan wrote:


Honestly I think I'm just confused.
I guess ways /do have/ official names, it's just that I keep on 
thinking about the possible /conceptual/ conflicts between two 
different Routes under one way (this statement probably doesn't 
make sense).


Also, I'm someone who loves relations and finds myself thinking about 
putting all of the elements that share a tag under a relation constantly!

I guess just keeping them in their original Ways is the way to go.

However, /if there was a way/ to indicate the "primary" relation for a 
Way, then I'd be all for it.

IDK. Save space wherever possible seems to be the common theme.
Problems with this though would be that renderers/data consumers would 
have to go into the relation every time they want to find more tags 
for an element.

There are pros and cons. I'm also aware relations aren't categories.

Thank you for the clarification.

On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
mailto:hi...@hiddewieringa.nl>> wrote:


Hello,

Route relations 'group' together the nodes/ways/relations that
form a cycling route. The nodes/ways/relations themselves should
not be tagged with the name of the route, like you quoted the wiki.

The name of a way should be the official name of the way, not the
name of the relation(s) that way is part of. I refer to Key:name
[1] which states "The names should be restricted to the name of
the item in question only and should not include additional
information not contained in the official name such as categories,
types, descriptions, addresses, refs, or notes."

So the question remains for the ways you mention that are tagged
with name of the cycling route. Are those ways officially named
exactly as the relation name? If not, I would classify this
situation as 'tagging for the renderer' (getting the renderer to
show the name of the cycling route).

On the subject of rendering: there are many renderers that show
cycling route relations [2]. Some of them [3] are even advanced
enough to grasp the concept of 'superroutes'/'parentroutes' [4]
that are common when tagging gigantic routes that span Europe like
the EuroVelo cycling routes [5].

    Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Key:name
<https://wiki.openstreetmap.org/wiki/Key:name>
[2]
https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
<https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps>
[3] https://cycling.waymarkedtrails.org
<https://cycling.waymarkedtrails.org>
[4] https://wiki.openstreetmap.org/wiki/Relation:superroute
<https://wiki.openstreetmap.org/wiki/Relation:superroute>
[5]
https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
<https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873>



On 16-11-2020 17:17, Seth Deegan wrote:


The Cycle Routes Wiki Page

<https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks>
states:

"It is preferred to tag the cycle routes using relations
instead of tagging the ways."

If I come across a route that has the Ways already tagged with
the name <https://wiki.openstreetmap.org/wiki/Key:name>=* of the
route, can I delete the name
<https://wiki.openstreetmap.org/wiki/Key:name>=*s in the Ways and
just create a Route Relation with the name?

I assume this is not prefered because a number of applications
use the names in the Ways themselves and not the Route Relation,
most notably osm-carto.

However, some benefits of doing this might be:

  * Takes up less space in

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Hidde Wieringa

Hello,

Route relations 'group' together the nodes/ways/relations that form a 
cycling route. The nodes/ways/relations themselves should not be tagged 
with the name of the route, like you quoted the wiki.


The name of a way should be the official name of the way, not the name 
of the relation(s) that way is part of. I refer to Key:name [1] which 
states "The names should be restricted to the name of the item in 
question only and should not include additional information not 
contained in the official name such as categories, types, descriptions, 
addresses, refs, or notes."


So the question remains for the ways you mention that are tagged with 
name of the cycling route. Are those ways officially named exactly as 
the relation name? If not, I would classify this situation as 'tagging 
for the renderer' (getting the renderer to show the name of the cycling 
route).


On the subject of rendering: there are many renderers that show cycling 
route relations [2]. Some of them [3] are even advanced enough to grasp 
the concept of 'superroutes'/'parentroutes' [4] that are common when 
tagging gigantic routes that span Europe like the EuroVelo cycling 
routes [5].


Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Key:name
[2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
[3] https://cycling.waymarkedtrails.org
[4] https://wiki.openstreetmap.org/wiki/Relation:superroute
[5] 
https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873



On 16-11-2020 17:17, Seth Deegan wrote:


The Cycle Routes Wiki Page 
<https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks> 
states:


"It is preferred to tag the cycle routes using relations instead
of tagging the ways."

If I come across a route that has the Ways already tagged with the 
name <https://wiki.openstreetmap.org/wiki/Key:name>=* of the route, 
can I delete the name 
<https://wiki.openstreetmap.org/wiki/Key:name>=*s in the Ways and just 
create a Route Relation with the name?


I assume this is not prefered because a number of applications use the 
names in the Ways themselves and not the Route Relation, most notably 
osm-carto.


However, some benefits of doing this might be:

  * Takes up less space in the DB
  * More tags that apply to the whole coute could be added to the
Relation like surface
<https://wiki.openstreetmap.org/wiki/Key:surface>=* and source
<https://wiki.openstreetmap.org/wiki/Key:source>=* (like the
official map of the route).
  * Ways with two or more routes wouldn't be tagged name
<https://wiki.openstreetmap.org/wiki/Key:name>=route 1 & route 2

<https://wiki.openstreetmap.org/w/index.php?title=Tag:name%3Droute_1_%26_route_2=edit=1>
 and
instead have their respective Relations. This could help with
preferred routing/data usage in general.


I would propose that /all/ routes and their names should be tagged in 
a Relation and /never/ the Ways, even if the Route Relation only has 
/one member/.


This way data consumers know that all Routes are going to be 
relations. Also future Routes mapped that share the Way of a Route 
that does not have Relation, won't require the mapper to shift all of 
the data stored in the Way to a new Relation.


Also, if Proposed features/Relation:street 
<https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:street> is 
ever approved, this would help establish a consistent OSM-wide routing 
standard.


*
*

*As for now*, I do not think that we should be deleting the name 
<https://wiki.openstreetmap.org/wiki/Key:name>=*s of Ways. However, I 
think osm-carto /should/ render and /prefer/ to render Relation names 
for Cycle routes over the names of the Ways. The Editors should also 
somehow influence users to map Relations for Cycle routes instead of 
naming them.



Thoughts?

Seth Deegan (lectrician1)

___
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] Power line going underground

2020-11-09 Thread Hidde Wieringa

Hello,

You could use "line_management=transition" (and according to the wiki 
also "location:transition=yes"). See for more examples the wiki 
https://wiki.openstreetmap.org/wiki/Tag%3Aline_management%3Dtransition 
with similar entries as the photo you posted.


Whether this suppresses the warning in JOSM, I do not know.

Kind regards,
/Hidde/


On 09-11-2020 18:40, Tod Fitch wrote:

There are a number of places where an above ground power line transitions to 
below ground. I am not equipped to guess where the line runs once it goes below 
ground so I stop mapping at the last power pole.  However the validation in 
JOSM flags this with a warning and I hate warnings on my edits. Is there some 
tag to put on the last power pole to indicate this is not an issue? I don’t see 
tagging for this situation described in the wiki.

See https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w for an example of 
this.

Thanks!



___
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] tourism=caravan_site versus tourism=camp_site: camping with a tent

2020-08-16 Thread Hidde Wieringa
Indeed. It is interesting to see that caravan_site is rendered 
conditionally in OpenCampingMap (only when further tags like tents 
tents, caravans, private, groups_only, etc. are given). Camp_sites are 
always rendered as far as I can find [1] [2].


Dalaas caravan_site is not rendered [3] [4], while the caravan_site in 
Murg [5] [6] has tents=yes and is rendered.


Trusting the knowledge behind OpenCampingMap, it would seem that unless 
a caravan_site is tagged specifically with tents=yes, it is not possible 
to camp with a tent on a caravan_site.


This observation is in line with my earlier proposal to make 
caravan_site *not* allow tents/camping by default. If tents are allowed 
("They may also have some space for tents." on the wiki), then the 
caravan_site should be tagged explicitly with tents=yes.
Are there any objections against this proposed change to the 
caravan_site wiki?


Kind regards,/
Hidde
/

[1] https://www.openstreetmap.org/way/283021236
[2] https://opencampingmap.org/#17/47.18396/9.25374/1/1/bef
[3] https://www.openstreetmap.org/way/129861804#map=17/47.12228/9.99663s 
<https://www.openstreetmap.org/way/129861804#map=17/47.12228/9.99663>

[4] https://opencampingmap.org/#16/47.1235/9.9975/1/1/bef
[5] https://www.openstreetmap.org/way/193412043
[6] https://opencampingmap.org/#16/47.1139/9.2110/1/1/bef

/
/

On 16-08-2020 08:16, Warin wrote:

On 15/8/20 4:49 am, Hidde Wieringa wrote:


Good day,

I am having trouble with the tourism tags caravan_site and camp_site, 
specifically for the use case of finding a place to camp with a tent 
(so not a caravan or a camper van).


My goal is to differentiate the two tags. Both tags allow tents, and 
both allow camper vans and caravans. Both tags may or may not provide 
facilities such as toilets, water, electricity, et cetera. In 
practice, the only thing that differentiates a pitch for a tent 
versus a pitch for a caravan or camper van, is the ground underneath 
(tents require some sort of soft material like grass). This 
differentiating property is not mentioned at all in the Wiki.


- The tag tents=yes/no (only listed in the camp_site Wiki) would be a 
good way to find a place to camp with a tent, but almost none of the 
caravan_site have this tag. All camp_sites in OSM I have camped on, 
allowed tents.
- Some of the caravan_site have been tagged with amenity=parking or 
even surface=asphalt and this would mean that camping with a tent is 
definitely not possible.
- I noticed that both of the tags have status 'de facto', and no 
proposals have been made for the definition of said tags. I found an 
abandoned proposal [1] that has a good discussion about camping [2].
- Some camp_sites have a 'nested' polygon with a caravan_site. This 
seems logical, and the caravan_site can be ignored, and the camp_site 
can be used for camping with a tent.


Statistics from TagInfo: camp_site has ~100,000 uses, and 
caravan_site has ~30,000 uses.


I ran a quick Overpass query for a small number of caravan sites 
(~15) [3]. Some of them note on their website that camping with a 
tent is possible, and the surface of the pitches seems to be grass. I 
am wondering if these should be re-tagged as camp_site, or if I am 
missing something.


My opinion would be that a camp_site should allow staying overnight 
with many types of vehicles/tents, indicated by the tags listed 
clearly on the wiki of camp_site. A caravan_site would allow staying 
overnight with vehicles only, and not allow camping with a tent. 
Concretely the sentence "They may also have some space for tents." on 
[4] is the problem. Replacing the sentence on the wiki with "Camping 
with a tent is not possible." would remove any ambiguity 
differentiating these tags.


Any comments are welcome. I am willing to update the wiki or draft a 
proposal for differentiating these two tags, if necessary.


Kind regards,
/Hidde Wieringa/

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site
[2] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_camp_site#caravan_site_separated.3F 

[3] https://tyrasd.github.io/overpass-turbo 
<https://tyrasd.github.io/overpass-turbo/?q=LyoKVGhpcyBoYcSGYmVlbiBnxI1lcmF0ZWQgYnkgdGhlIG92xJJwxIlzLXR1cmJvIHdpemFyZC7EgsSdxJ9yaWdpbmFsIHNlxLBjaMSsxIk6CsOiwoDCnHRvxKjEhW09Y8SwYXZhbl9zacSVIMWVxJfElW50cz1ub8WIwp0KKi8KW8WMdDpqc29uXVt0aW1lxaw6MjVdOwovL8SPxJTEnXIgcmVzdWzFoAooCiAgxoAgcXXEksSaxKNydCBmb3I6IMWIxYrFjMS3c8WPxZHEk8WUxZbFmMWaxZzEm8SNxaDFosWkwoDFpsaQxaNkZVsixYvFjcalIj0ixqfFk8WVxZfFmWUixbMhxZ7FoF0oe3tixKp4fX0pxb7GkHdheca5xrvGpG3GvseAxZLGqceExJXHh1vHicavc8eMx47HkG_HkseUx5bGhmVsxJRpxbHHm8ajxY7Hn8eBx6LGq8eGx4jHisepx43Hj8eRx5PHlQrIhsaScMS3xZ_HscaJxotzCsWsxJhvZHnFvj7FvsiSc2vHssaTdDs=BNxUhr7BxL;>

[4] https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcaravan_site



The web site https://opencampingmap.org/#10/48.6100/8.2400/0/1/bef is 
an attempt to encourage m

[Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent

2020-08-14 Thread Hidde Wieringa

Good day,

I am having trouble with the tourism tags caravan_site and camp_site, 
specifically for the use case of finding a place to camp with a tent (so 
not a caravan or a camper van).


My goal is to differentiate the two tags. Both tags allow tents, and 
both allow camper vans and caravans. Both tags may or may not provide 
facilities such as toilets, water, electricity, et cetera. In practice, 
the only thing that differentiates a pitch for a tent versus a pitch for 
a caravan or camper van, is the ground underneath (tents require some 
sort of soft material like grass). This differentiating property is not 
mentioned at all in the Wiki.


- The tag tents=yes/no (only listed in the camp_site Wiki) would be a 
good way to find a place to camp with a tent, but almost none of the 
caravan_site have this tag. All camp_sites in OSM I have camped on, 
allowed tents.
- Some of the caravan_site have been tagged with amenity=parking or even 
surface=asphalt and this would mean that camping with a tent is 
definitely not possible.
- I noticed that both of the tags have status 'de facto', and no 
proposals have been made for the definition of said tags. I found an 
abandoned proposal [1] that has a good discussion about camping [2].
- Some camp_sites have a 'nested' polygon with a caravan_site. This 
seems logical, and the caravan_site can be ignored, and the camp_site 
can be used for camping with a tent.


Statistics from TagInfo: camp_site has ~100,000 uses, and caravan_site 
has ~30,000 uses.


I ran a quick Overpass query for a small number of caravan sites (~15) 
[3]. Some of them note on their website that camping with a tent is 
possible, and the surface of the pitches seems to be grass. I am 
wondering if these should be re-tagged as camp_site, or if I am missing 
something.


My opinion would be that a camp_site should allow staying overnight with 
many types of vehicles/tents, indicated by the tags listed clearly on 
the wiki of camp_site. A caravan_site would allow staying overnight with 
vehicles only, and not allow camping with a tent. Concretely the 
sentence "They may also have some space for tents." on [4] is the 
problem. Replacing the sentence on the wiki with "Camping with a tent is 
not possible." would remove any ambiguity differentiating these tags.


Any comments are welcome. I am willing to update the wiki or draft a 
proposal for differentiating these two tags, if necessary.


Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site
[2] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_camp_site#caravan_site_separated.3F 

[3] https://tyrasd.github.io/overpass-turbo 
<https://tyrasd.github.io/overpass-turbo/?q=LyoKVGhpcyBoYcSGYmVlbiBnxI1lcmF0ZWQgYnkgdGhlIG92xJJwxIlzLXR1cmJvIHdpemFyZC7EgsSdxJ9yaWdpbmFsIHNlxLBjaMSsxIk6CsOiwoDCnHRvxKjEhW09Y8SwYXZhbl9zacSVIMWVxJfElW50cz1ub8WIwp0KKi8KW8WMdDpqc29uXVt0aW1lxaw6MjVdOwovL8SPxJTEnXIgcmVzdWzFoAooCiAgxoAgcXXEksSaxKNydCBmb3I6IMWIxYrFjMS3c8WPxZHEk8WUxZbFmMWaxZzEm8SNxaDFosWkwoDFpsaQxaNkZVsixYvFjcalIj0ixqfFk8WVxZfFmWUixbMhxZ7FoF0oe3tixKp4fX0pxb7GkHdheca5xrvGpG3GvseAxZLGqceExJXHh1vHicavc8eMx47HkG_HkseUx5bGhmVsxJRpxbHHm8ajxY7Hn8eBx6LGq8eGx4jHisepx43Hj8eRx5PHlQrIhsaScMS3xZ_HscaJxotzCsWsxJhvZHnFvj7FvsiSc2vHssaTdDs=BNxUhr7BxL;>

[4] https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcaravan_site

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


Re: [Tagging] bicycle_parking=? for stands where handlebar is used to hold bicycle in position

2020-06-15 Thread Hidde Wieringa

Good evening,

In the region where I live there are 657 objects tagged with 
amenity=bicycle_parking, of which 457 have no bicycle_parking tag at 
all. I would say that classification of the bicycle_parking is 
undertagged in general.


Parking the bicycle by handlebar is not the norm in The Netherlands, but 
there are many instances of handlebar bicycle parking (I have no numbers 
on this though) [1] [2]. Especially at schools and places that need to 
be kept clean (because the bicycles do not 'clutter' when they are 
parked). It is also compatible with most types of bicycles, and there is 
no danger of bending the wheel when parked. I hope that by introducing 
this additional tag on the wiki more amenity=bicycle_parking can be 
classified correctly (and fully).


At this moment the tagging of bicycle_parking=handlebar_holder only 
exists in Switzerland, and one node which I created just now in The 
Netherlands.


I agree that a full proposal to add this tag would not add anything.

As for editor support.
- ID editor: and bicycle_parking is a free-form-taginfo-autocompleted 
field. Once the tag is used enough it will be autocompleted in the 
combobox. No action is necessary. [3]
- JOSM: the list is hard-coded, and may need to be expanded. This would 
be a simple patch to the presets. [4]
- StreetComplete: The linked issues show an interesting discussion. It 
is unclear if an additional way of parking a bicycle would be a problem 
if it is sufficiently different from the existing types in the app (the 
main argument in the linked issues).


Kind regards,
/Hidde Wieringa/

[1] (NL) https://bike-safe.nl/index.php/fietsparkeeroplossingen/stuurdrager

[2] (NL) 
https://www.falco.nl/producten/fietsparkeren/fietsenrekken/stuurdraagsysteem-falcohanger.html

//

[3] 
https://github.com/openstreetmap/iD/blob/c5c76b3/data/presets/presets/amenity/bicycle_parking.json


[4] 
https://josm.openstreetmap.de/browser/trunk/resources/data/defaultpresets.xml?rev=16646#L2456



On 14-06-2020 21:16, Mateusz Konieczny via Tagging wrote:




Jun 14, 2020, 20:51 by lukas.toggenbur...@fhgr.ch:

Do we need additional steps to make this value "official"?

You can go through a https://wiki.openstreetmap.org/wiki/Proposal_process
but it is unlikely to add anything.

You can try asking for support in editors (JOSM presets etc), but not 
sure how necessary
it is. Is it popular and significantly undertagged in some regions or 
is it rare and exotic type?


I would like to propose it as an additional option in
StreetComplete ( https://github.com/westnordost/StreetComplete )
but don't want to do it prematurely.

It appears to be extremely rare (based on number of tags so far), so 
it is likely that
answer will be "for rare situations the can't say option that will 
leave a freeform note is available"


See also https://github.com/westnordost/StreetComplete/issues/1202
https://github.com/westnordost/StreetComplete/issues/1038 that are 
related.


See also initial discussion in 
https://github.com/westnordost/StreetComplete/pull/923


Note: I am not a maintainer of StreetComplete - but I would encourage 
looking

through what I linked before creating a new issue

___
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] bicycle_parking=? for stands where handlebar is used to hold bicycle in position

2020-06-14 Thread Hidde Wieringa
The table with value in the bicycle_parking wiki has been updated with 
this new value handlebar_holder.


The photo has been uploaded to WikiMedia Commons (CC0).

Kind regards,/
Hidde Wieringa/

/
/

On 13-06-2020 23:22, Mateusz Konieczny via Tagging wrote:
Can you take your own photo of such bicycle parking and upload it to 
Wikimedia Commons ( https://commons.wikimedia.org/wiki/Main_Page )?


Given that it is a clearly distinct bicycle parking type it would be 
nice to add it to the list on Wiki.


Jun 13, 2020, 21:56 by hi...@hiddewieringa.nl:

Hello,

The wiki for bicycle_parking suggests that additional values may
be used. When I look in the TagInfo for the key
https://taginfo.openstreetmap.org/keys/bicycle_parking, then I
find bicycle_parking=handlebar_holder which seems to fit your
description/photo.

See some example locations here: https://overpass-turbo.eu/s/V2l

For completeness, these methods of parking your bicycle also exist
in The Netherlands.

Kind regards,/
Hidde Wieringa/


On 13-06-2020 21:47, Mateusz Konieczny via Tagging wrote:

It probably needs a new value, maybe one
not yet documented on that page.

Looks like equivalent of bicycle_parking=ground_slots
(0 security, but designated place to leave bicycle)
but is something different.


Jun 13, 2020, 20:52 by lukas.toggenbur...@fhgr.ch
<mailto:lukas.toggenbur...@fhgr.ch>:

Hi all

The kind of bicycle stand you can see in the attached picture
is present every then and when in Switzerland and possibly in
other parts of the world as well.

How would you tag this? None of the values described at
https://wiki.openstreetmap.org/wiki/Key:bicycle_parking seem
to fit well.

Best regards

Lukas



___
Tagging mailing list
Tagging@openstreetmap.org  <mailto: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] bicycle_parking=? for stands where handlebar is used to hold bicycle in position

2020-06-13 Thread Hidde Wieringa

Hello,

The wiki for bicycle_parking suggests that additional values may be 
used. When I look in the TagInfo for the key 
https://taginfo.openstreetmap.org/keys/bicycle_parking, then I find 
bicycle_parking=handlebar_holder which seems to fit your description/photo.


See some example locations here: https://overpass-turbo.eu/s/V2l

For completeness, these methods of parking your bicycle also exist in 
The Netherlands.


Kind regards,/
Hidde Wieringa/

//

On 13-06-2020 21:47, Mateusz Konieczny via Tagging wrote:

It probably needs a new value, maybe one
not yet documented on that page.

Looks like equivalent of bicycle_parking=ground_slots
(0 security, but designated place to leave bicycle)
but is something different.


Jun 13, 2020, 20:52 by lukas.toggenbur...@fhgr.ch:

Hi all

The kind of bicycle stand you can see in the attached picture is
present every then and when in Switzerland and possibly in other
parts of the world as well.

How would you tag this? None of the values described at
https://wiki.openstreetmap.org/wiki/Key:bicycle_parking seem to
fit well.

Best regards

Lukas



___
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] Tagging and rendering places without a name

2020-04-18 Thread Hidde Wieringa

Hello,

This is the first time posting to this mailing list. In case this is the 
wrong place to post my question, feel free to point me to the correct 
mailing list/forum.


I opened an issue in the OSM carto Github repository 
(https://github.com/gravitystorm/openstreetmap-carto/issues/4115) with 
the question if places tagged with place=* but without a name could be 
rendered. The follow-up pull request 
https://github.com/gravitystorm/openstreetmap-carto/pull/4120 proposes a 
rendering for unnamed places.


A discussion erupted, about the conceptual consequences of rendering a 
place without a name. This goes against the wiki 
(https://wiki.openstreetmap.org/wiki/Key:place) where the tag name=* is 
marked as required. The first line in the wiki is /"Used to indicate 
that a particular location is known by a particular name, to indicate 
what sort of "place" it is. [...]"/. However indicating what sort of 
place it is, does not require a name. Indicating that a place of some 
sort exists at a certain location is also valuable data (a quick count 
of Nigeria gives ~9800 nodes of places without a name versus ~69000 
nodes of places with a name).


I wish to question the assumption that every place always has or 
requires a name. The comment of 'sommerluk' on the Github issue 
(https://github.com/gravitystorm/openstreetmap-carto/issues/4115#issuecomment-612847759) 
indicates that there may indeed be small populated places without a 
name, although larger populated places always have a name in practice.


Also, regions of the world where on-the-ground mapping is not popular 
will mostly be mapped by remote mappers. Because of that, mapped places 
will usually not get a name (yet), because mappers are not locally 
familiar with the place. The data is still useful for humanitarian aid 
(for example see 
https://tasks.hotosm.org/contribute?difficulty=ALL=nigeria for the 
many projects in the HOT tasking manager for improving data in Nigeria, 
in particular missing residential areas). Rendering these places in a 
visual way makes using the data easier. Later, the unnamed places could 
still be given a name by a mapper with that knowledge.


The tough question is when some place is considered a 'place' and may be 
mapped when the name is unknown.


I am curious about further reactions on this topic.

Kind regards,
/Hidde Wieringa/

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