Re: [Tagging] Feature Proposal - Voting - Pumping proposal

[Yves via Tagging]

Given the number exposed here by Martin, and the fact that there is a few 
established data consumers, I think that preserving the pump tag as it is now 
and refine it with another tag would be a good idea indeed.
Yves 

Le 22 novembre 2020 02:58:07 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 22. Nov 2020, at 02:32, François Lacombe  
>> wrote:
>> 
>> It's true proposed tagging deprecates the current pump=* definition 
>> according to rationale and wishes to use the pump word in a more appropriate 
>> way.
>
>
>this would deprecate around 20k pump values describing a pump type, plus 15k 
>yes/no.
>
>Looking at the no-values, 23% are not in combination with man_made 
>https://taginfo.openstreetmap.org/tags/pump=no#combinations
>i.e. this is also used on other objects to state buildings there is no pump.
>I would also suggest you modify your proposal in a way that it is compatible 
>with the current use of the pump tag
>
>Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[Yves via Tagging]

And hazards for niche practices (climbing, whitewater sports, ski touring,...) 
that are actually mapped in OSM are not generally signposted or 'official'.
Maybe we can't expect this proposal to cover them, but you can't prevent users 
to use the tag hazard to map them.
Yves 

Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
>tagging@openstreetmap.org>:
>
>>
>>- It is not explicitly mentioned, but it would be a good idea to have
>>explicit mention
>>- is it OK to tag hazard that
>>-
>>- - exists
>>- - is unsigned
>>- - government has not declared that it exists (maybe government is
>>dysfunctional/missing like
>>- in Somalia, or it is covering-up the problem, or it has higher
>>priorities - for example during war)
>>
>>
>
>+1. This may also depend on the context. The same kind of hazard on a road
>may well be signposted, but not on a hiking trail in a forest.
>
>Cheers,
>Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[Yves via Tagging]

Le 5 décembre 2020 19:19:31 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>you guys are finding real world examples for every weird situation that nobody 
>expected to even exist. Traffic lights for rock fall somewhere?
>
>Cheers Martin  
They are no so rare, I remember one going down from La Grave toward Grenoble in 
the alps. No picture at hand though, and not sure they belong or not to the 
road section that has to be rebuilt. 

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

Re: [Tagging] Animal trails

[Yves via Tagging]

Creating a new tag for this is not a bad idea.
Yves 

Le 30 novembre 2020 21:27:33 GMT+01:00, Seth Deegan  a 
écrit :
>You could add a `note=*` to every element. You should probably contact the
>mappers of that region and explain to them not to add them.
>
>I agree that in this case, mapping animal tracks is *especially *necessary.
>If someone isn't going to map it now, they're going to do so in the future
>(as you've seen), incorrectly.
>
>On a related idea, OSM should probably implement "Area Notes" into the API
>to notify mappers how to map specific areas.
>
>lectrician1 
>
>
>On Mon, Nov 30, 2020 at 1:44 PM s8evq  wrote:
>
>> Hello everyone,
>>
>> With the Belgian community, we have been in contact with Natuurpunt, our
>> main national nature conservation organization. They are slowing using more
>> and more OSM and recently came to us with the following remark.
>>
>>
>> "Some mappers have added paths that are not actually real paths for
>> humans, but simply flattened walking routes made by the cows. I assume that
>> these are visible on aerial photographs, and in the field they may also
>> look like trails. However, it is really not the intention that people
>> should walk there. They change regularly and we also do not want to put
>> signs 'forbidden entry' all over the area.
>> We could delete them from OSM, but then of course soon later, an active
>> micromapper might add them again."
>>
>> Most people seem to think paths made by cattle or wildlife should NOT be
>> mapped at all (
>> https://www.openstreetmap.org/user/Pascal%20Cuoq/diary/1). However,
>> when there are micromappers around, they tend to map ALL THE THINGS. Not
>> mapping these "animal trails" that you know about, means they will likely
>> show up on the map as a simple highway=path, added by somebody else.
>> Therefor, we would prefer to map them with a tag like highway=animal_track,
>> to make sure mappers see that this thing was analyzed before and should NOT
>> be mapped as a regular path. Do you have any suggestions for a tag or a
>> different approach?
>>
>> 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] Elevated housing estate

[Yves via Tagging]

I guess the level won't be completely sealed and may serve for something once 
the building is inhabited.
Wait and them!
Yves 

Le 25 novembre 2020 02:26:22 GMT+01:00, Graeme Fitzpatrick 
 a écrit :
>On Wed, 25 Nov 2020 at 11:20, Joseph Eisenberg 
>wrote:
>
>> Is the whole ground level a parking lot or parking structure, perhaps?
>>
>
>No.
>
>It's built right beside a Creek, on a flood-plain (yeah, thanks Council!),
>so it's done like that so that the apartments are up away from the water
>the next time the Creek floods!
>
>Thanks
>
>Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Yves via Tagging]

I don't think they can be categorized with the ones designed to make noise.
It looks like they are intended to work as bumps, but cheaper and easier to 
install.
Yves 

Le 19 décembre 2020 23:47:29 GMT+01:00, Warin <61sundow...@gmail.com> a écrit :
>On 20/12/20 9:24 am, Brian M. Sperlongano wrote:
>> I've seen these in the US also, but I never knew what they were 
>> called.  I understand that the purpose of them is simply to make noise 
>> when a car drives over them, as they don't slow you down in any 
>> appreciable way like a speed bump/hump.
>>
>> We already have a tag for "a traffic calming device that makes noise 
>> when a car drives over it", which is a rumble strip 
>> (see: traffic_calming=rumble_strip).  Note, I am talking about the 
>> kind that go all the way across the road, and not the kind in the 
>> shoulder of the road that make noise when you veer out of your lane.
>>
>> I usually think of rumble strips as grooves in the road, but it 
>> strikes me that these micro-speed-bump things are essentially the same 
>> thing -- they make noise when a car goes over it to alert the driver 
>> of something.
>>
>> I'm uncomfortable with hillock/hillocky as a value. Cursory searches 
>> seem to indicate that this isn't a term in use, in any flavor of English.
>
>
>Rumble strips I am familiar with. They not only cause a noise but a 
>vibration too, felt by the people inside the vehicle but not a large 
>vehicle deflection.
>
>Are the simply a new kind of rumble strip? So 
>traffic_calming=rumble_strip, rumble_strip:structure=circle, 
>rumble_strip:orientation=transverse
>
>Alternatively perhaps a better name would be rumble circles?
>
>
>>
>> On Sat, Dec 19, 2020 at 5:08 PM Martin Koppenhoefer 
>> mailto:dieterdre...@gmail.com>> wrote:
>>
>>
>>
>> sent from a phone
>>
>> > On 19. Dec 2020, at 22:53, Jeremy Harris > > wrote:
>> >
>> > traffic_calming=multi_bump  ?
>>
>>
>> or
>> traffic_calming=mini_bumps ?
>>
>> when they come up with something smaller that could still be
>> micro_bumps ;-)
>>
>>
>> Cheers Martin
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Yves via Tagging]

Maybe it's time to create a sub-category of traffic_calming=bump with another 
tag for the peace of mind of data consumer and not bridle too much (though I 
think it is not possible) the creativity of traffic calming features creators?
Yves 

Le 20 décembre 2020 11:42:56 GMT+01:00, "Tomáš Hurýn"  a 
écrit :
>ok, so we can call value fo this tag: circle_humps. What do you all think of 
>it?
>
>Dne neděle 20. prosince 2020 0:31:07 CET, 80hnhtv4agou--- via Tagging 
>napsal(a):
>> Round Circle Speed Humps
>> 
>> >Saturday, December 19, 2020 5:29 PM -06:00 from Paul Allen
>> >: 
>> >
>> >On Sat, 19 Dec 2020 at 23:19, 80hnhtv4agou--- via Tagging < 
>tagging@openstreetmap.org > wrote:
>> >>https://streetsolutionsuk.co.uk/collections/speed-ramps/products/round-yel
>> >>low-circle-speed-humps-50mm?variant=19772633645113>
>> > 
>> >That didn't take me where you intended.  I had to navigate from where I
>> >ended up to those things.  Ended up at the URL you gave, but couldn't get
>> >there directly.  It calls them speed bumps.  Which doesn't answer my
>> >original question of whether the word "bumb" in the proposal was a typo or
>> >yet another kind of traffic calming device.
>> > 
>> >It also doesn't directly answer if these function in the same way as
>> >rumble strips or as speed bumps, but from the name I'd guess
>> >they're not an alternative to rumble strips.
>> > 
>> >--
>> >Paul
>> > 
>> 
>>  
>>  
>>  
>>  
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic cartography features missing, why?

[Yves via Tagging]

Good initiative Martin, at first sight I'll make two comments :
* CC0 doesn't allow to derive data from OSM
* as geometries are fuzzy in nature, there should be a way to accept several 
geometries for a same entity, be it only to avoid long discussions on boundaries
Yves 

Le 8 novembre 2020 09:47:04 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 8. Nov 2020, at 09:24, Mateusz Konieczny via Tagging 
>>  wrote:
>> 
>> I really like an idea of separate database/layer for such fuzzy objects.
>
>
>I have started a project to collect such fuzzy objects. Data is stored in a 
>git repo in Geojson representation. Pull requests welcome.
>https://github.com/dieterdreist/OpenGeographyRegions
>
>Cheers Martin 
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic cartography features missing, why?

[Yves via Tagging]

Maybe I'm wrong, but can I use OSM tiles to help tracing a 'Blue Valley' 
polygon, simplify or copy a multipolygon 'Martin' s wood' or whatever and 
declare it cc0? 
Yves 


Le 8 novembre 2020 11:08:57 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 8. Nov 2020, at 10:08, Yves  wrote:
>> 
>> * CC0 doesn't allow to derive data from OSM
>
>
>it does. The whole point (for me) to start this was to provide data that can 
>be combined with OpenStreetMap. What would be your suggestion for a licence? I 
>would be willing to double licence it with WTFPL, would that help?
>
>
>Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecate water=pond?

[Yves via Tagging]

We should get rid of all tags too close to natural language.
I propose a unified tagging scheme:
material = dihydrogen monoxyde
formula = H2O
flowing = yes/no
depth = xx

Wait, in fact this could be extended to anything from building to trees!!
Yves 

Le 10 novembre 2020 06:26:39 GMT+01:00, Joseph Eisenberg 
 a écrit :
>The tag water=pond was added with a large number of other types of
>"water=*" in 2011, but it has a poorly defined description.
>
>"A pond : a body of standing water,
>man-made in most cases, that is usually smaller than a lake. Salt
>evaporation ponds should be tagged with landuse
>=salt_pond
>, open-air
>swimming pools — with leisure
>=swimming_pool
>."
>
>So it might be artificial, like a landuse=reservoir or water=reservoir, but
>smallish. Or it might be natural like a water=lake, but smallish. However,
>nothing on the water=lake page defines a lower limit for the size of a lake.
>
>This is a shame, because all the other values of water=* are clearly
>defined as only natural, or only artificial, and waterway=* features are
>also clearly divided. Furthermore, the original lags landuse=reservoir and
>landuse=basin were also clearly artificial, while lakes were natural.
>
>But the biggest problem is that there is no way to define a lower size for
>a lake or reservoir, or an upper size for a pond. And the size of the area
>is easier available from the geometry of the feature, so it doesn't need to
>be mentioned in the tag.
>
>I think the best option is to deprecate water=pond and suggest using
>water=lake for natural lakes, even small ones, and use water=reservoir or
>water=basin (or landuse=reservoir or =basin if you prefer) for the
>artificial ones.
>
>-- Joseph Eisenberg
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Yves via Tagging]

On the history of elements, this tool is particularly good I think :
https://osmlab.github.io/osm-deep-history/
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic cartography features missing, why?

[Yves via Tagging]

Le 9 novembre 2020 10:08:42 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>Am Mo., 9. Nov. 2020 um 09:37 Uhr schrieb Mateusz Konieczny via Tagging <
>tagging@openstreetmap.org>:
>
>> In short: technically CC0 may be used, but it would be confusing as ODBL
>> would still
>> apply anyway.
>>
>> See https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0
>>
>> "CC0 licenced material is in general compatible, however the license only
>> extends
>> to material the licensor actually has rights in and specifically avoids
>> making a
>> statement on the status of any third party material included."
>>
>> So you could license this as CC0, but it does not mean that other
>> limitations are
>> not applying (limited extraction of just some shapes from OpenStreetMap may
>> be doable without triggering ODBL - see
>>
>> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline
>> but such project would likely quickly pass it).
>>
>
>
>For the avoidance of doubt, there is currently no data from OpenStreetMap
>in OpenGeographyRegions, and there will not be in the future, so that the
>data can be used without limitations. My intention is using it together
>with OSM data, but of course you can use it with whichever data you want.
>
>These regions, although it would be legally possible, should not be
>imported in OSM either, because they are in medium and large scale
>resolution and not suitable by their nature (not well defined on small
>scales, fuzzy boundaries, etc.).
>
>Cheers
>Martin

Ah, I thought this could be used to host extremely big fuzzy MPs that we 
otherwise do not welcome in OSM. 
Yves 

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

Re: [Tagging] Basic cartography features missing, why?

[Yves via Tagging]

Le 7 novembre 2020 12:47:45 GMT+01:00, Tomas Straupis  
a écrit :
> Fuzzy features (like
>continents, mountain ranges, bays etc. should probably be moved to a
>separate database).
>
I often thought an 'Openlabelmap' database containing geometries to help with 
the labeling of such features could help solving the issue of mapping this 
larges or fuzzy geographical places the same manner we can map a bench or a 
road.
Yves 

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

Re: [Tagging] Feature Proposal - RFC - Artificial

[Yves via Tagging]

"Phase 4: All man_made tags to be removed 2031-01-01 00:00 UTC+0"
I think that is as reasonable as it could be.
Yves 

Le 21 octobre 2020 04:46:34 GMT+02:00, Robert Delmenico  a 
écrit :
>*Link to proposal page:*
>https://wiki.openstreetmap.org/wiki/Proposed_features/artificial
>*Definition*:  A tag for identifying human-made (artificial) structures
>added to the landscape.
>
>Please discuss this proposal on the discussion page for the proposal.
>
>Kind Regards,
>
>Robert Delmenico
>rtbk
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - lifecycle prefix vandalised:

[Yves via Tagging]

I'm not that much in favour of such a tag:
1) it's not about the current state of the element, but more on the cause of it.
2) It's temporary (hopefully)

Yves

Le 17 septembre 2023 12:50:21 GMT+02:00, Anne-Karoline Distel 
 a écrit :
>I'm proposing to establish the lifecycle prefix "vandalised:" which has
>been in use for at least 8 years in some form, but hasn't been documented.
>
>This was triggered by noticing this one:
>https://www.openstreetmap.org/node/11196545305 (unfortunately, I didn't
>take a photo).
>
>https://wiki.openstreetmap.org/wiki/Proposal:Vandalised:
>
>I'm not active in the forum, so if anyone wants to let people know
>there, that'd be fabulous.
>
>
>Cheers,
>
>Anne
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Use description instead of name for route relations

[Yves via Tagging]

It's never to late to fix a mistake? 
Yves 

Le 23 octobre 2023 09:46:05 GMT+02:00, Warin <61sundow...@gmail.com> a écrit :
>
>On 22/10/23 19:56, Martin Koppenhoefer wrote:
>> 
>> sent from a phone
>> 
>>> On 20 Oct 2023, at 10:23, Mateusz Konieczny via Tagging 
>>>  wrote:
>>> 
>>> maybe just removing this bad advise without proposal would be a good idea
>> +1
>> ___
>
>
>Issue: that wording is in the approved proposal for PTv2 ...
>
>Removing the wording is 'a good idea' .. but that would go against the 
>approved proposal .. catch 22.
>
>
>___
>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] Streets with gradually increasing widths

[Yves via Tagging]

I said that putting width on individual nodes is simple, and it's simple for 
the mapper, of course.
Depending on the routing software, accessing nodes data can already be tricky 
for the data consumer.
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Streets with gradually increasing widths

[Yves via Tagging]

Le 16 août 2023 01:43:48 GMT+02:00, Greg Troxel  a écrit :
>Timothy Noname  writes:
>
>> I've always thought actual measurements should be added to an individual
>> node and the minimum width should be on the way, splitting the way at
>> significant changes.
>
>This is an awesome suggestion.  It allows recording as much data as
>anybody wants to measure, and doesn't add any needless complexity.
>
>

That plus splitting the way are clearly the simpliest solutions. 
I doubt new tags width:start, end would ever be used by routers. 
Yves 

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

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Yves via Tagging]

"Please bear in mind that quite a lot of them can be re-tagged
automatically" 
Can you give a single example of similar automatic re-tagging in the past ?
Yves___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Yves via Tagging]

Le 15 septembre 2022 15:19:58 GMT+02:00, "Janko Mihelić"  a 
écrit :
>čet, 15. ruj 2022. u 14:52 Peter Elderson  napisao je:
>
>> Which combination(s) of highway values, sac scale values and hazard values
>> would exclusively represent a scramble (Dutch verb: klauteren, i.e. going
>> up or down there using hands and feet) to a grown-up, non-challenged,
>> average hiker without climbing skills and without special gear other then a
>> cane, hiking shoes and gloves?
>>
>
>Any of the three combinations:
>
>highway=path + sac_scale=alpine_hiking
>highway=path + sac_scale=demanding_alpine_hiking
>highway=path + sac_scale=difficult_alpine_hiking
>
>Janko

I'll add to the list the trail_visibility= you like. 
Yves 

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

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Yves via Tagging]

Peter, the sac_scale definition on the wiki is quite thorough. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] incline=up_and_down

[Yves via Tagging]

You can't really micromap until you micromap for real ;-)
More seriously, there may be no need to split ways down to the *exact* meter to 
give the router a sense of the way profile with incline=*.
Yves 

Le 26 septembre 2022 02:21:24 GMT+02:00, Mateusz Konieczny via Tagging 
 a écrit :
>tagging incline direction on ways with mtb:scale:uphill is useful
>as otherwise you need high-quality elevation model
>to do routing, and in some cases it may be unavailable at all in sufficient 
>detail
>
>
>I wanted to systematically tag mtb scale info in some places to improve routing
> for bicycle trekking.
>
>Some people (like myself) are NOT interested at all in MTB routes but 
>mtb:scale=1
>(or just mtb:scale=0) is still fine for them.
>
>
>
>
>So mtb:scale=1 mtb:scale:uphill=3 is fine downhill but not uphill for such 
>people,
> but it is hard to check in which way given path goes uphill
>
>
>
>This is also recommended by wiki:
>
>https://wiki.openstreetmap.org/w/index.php?title=Key:mtb:scale=en#mtb:scale:uphill=0-5
>
>So I wanted to systematically tag missing incline tags, as even without exact
>value it is already valuable info for routing.
>
>But what can be done in cases where there is no real incline but 
>path goes through series of up and down hops?
>
>In many cases it is deliberately engineered (legally or not)
>and looks often like https://www.moredirt.com/photo/91766
>https://www.zip06.com/local-news/20220622/rockland-preserve-pump-track-is-officially-a-hit/
> 
>https://www.bikehinton.com/hinton-bike-park
>-
>
>Would it be fine to tag incline=up_and_down in such case?
>https://taginfo.openstreetmap.org/tags/incline=up_and_down
>has some minimal use already.
>
>Or maybe incline:variable=yes?
>
>Splitting such way into incline=up / incline=down segments
>is too much for me and I was splitting footway into 20m
>segments to mark changing surface/lit status.
>
>-
>
>And why I want to tag some incline value? Because I want to do it
>systematically for all such ways.
>See https://github.com/streetcomplete/StreetComplete/pull/4385
>for the context (I want to also add it to StreetComplete if it will
>be accepted there).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Move proposal voting from wiki to the new forum

[Yves via Tagging]

Le 24 septembre 2022 10:47:53 GMT+02:00, Mateusz Konieczny via Tagging 
 a écrit :
>3) https://community.openstreetmap.org/t/votes-on-discourse/508
>strongly encourages voting without comment, further moving it
>from commenting with feedback to just a pure vote
>
>Is there a mode that requires and records comments from "no" votes?
>
>4) It divorces proposal content and vote making more likely that
>people will vote without even looking at proposal
>

3) and 4) above are serious arguments.

I would be cautious about voting: the wiki proposal process is a wiki + tagging 
list process which has certainly its flaws, and that is sanctioned in some way 
by voting on the wiki.
I think the new community site should be more integrated in the process before 
talking about voting. 
Yves 

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

Re: [Tagging] Feature Proposal - RFC - Require proposal announcements to be made on the new forum instead of the mailing list

[Yves via Tagging]

There is a 'follow' drop down at the end of a topic.
Yves 

Le 24 septembre 2022 19:19:17 GMT+02:00, Mateusz Konieczny via Tagging 
 a écrit :
>How can I do "There you can select to get emails"?
>
>Is it about 
>"Email me when I am quoted, replied to, my @username is mentioned,
>or when there is new activity in my watched categories, tags or topics"
>option in account settings?
>
>Because that seems more spammy than tagging mailing list.
>
>What worse, I cannot assign a separate email account from
>email assigned to my OSM account 
>(I have a separate account just for mailing lists due to volume)
>
>I see there "Email can be updated from authentication provider."
>without option to set a different one for Discourse notifications.
>
>Sep 24, 2022, 14:32 by tagging@openstreetmap.org:
>
>> Yes, if you click on a tag, you see all topics with that tag. On the top 
>> right, you see a bell icon. There you can select to get emails.
>>
>> That is why I proposed to use the tag "wiki-proposal" on all proposals (RFC) 
>> and votes. 
>>
>> Additionally, you can get an RSS feed. Click on a tag and add .rss to the 
>> website URL like: 
>> https://community.openstreetmap.org/tag/tagging.rss
>>
>> Greetings,
>> Vincent
>>
>>
>>
>> 24 sep. 2022 10:51 van 
>> tagging_at_openstreetmap_org_seblajk...@simplelogin.co:
>>
>>> (1)
>>> Is there a way to subscribe somehow to get notifications via email, without 
>>> getting
>>> notified about for example postings in talk-de subforum?
>>>
>>> "Using simple rss or email notifications, people can subscribe to new 
>>> proposals
>>> on the community." is mentioned but it is not clear how it can be done
>>>
>>> Sep 24, 2022, 09:34 by tagging@openstreetmap.org:
>>>
 Require proposal announcements to be made on the new forum instead of the 
 mailing list

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

 Please discuss this proposal on its Wiki Talk page.

 Greetings,

 Vincent

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

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Yves via Tagging]

Le 20 septembre 2022 19:04:59 GMT+02:00, martianfreeloader 
 a écrit :
>
>How about this:
>
>- keep highway=path for everything that can be walked by normal people (this 
>means we don't need to re-tag millions of ways)
>- introduce a new tag highway=demanding path for everything else.
>
 I think you forgot to mention we would need to re-tag the hundred of thousand 
ways falling into your second bullet. That's normal, we tend to forget how 
easily we manage competing tagging schemes ;-) 

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

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Yves via Tagging]

Tens of thousand in remote areas, where contributors are scarce, just to change 
 sac_scale=demanding_mountain_hiking to 
highway=demanding_mountain_hiking_alias, I don't see this going to get a lot of 
support. I'm also afraid that would put a lot of strain on a relatively small 
community of mappers mapping the great outdoors, maybe I'm wrong.
Yves___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names being applied to tracks/paths

[Yves via Tagging]

Remove the name of the way, put a name on each relations. Except if it makes 
sense to keep the name also on the way for whatever reason you see fit. 

Le 30 décembre 2022 18:06:12 GMT+01:00, Dave F via Tagging 
 a écrit :
>What do you do if there are two routes?
>
>DaveF
>
>On 30/12/2022 02:19, brad wrote:
>> +1
>> If the only name is the route name I think it makes good sense to put it on 
>> the local way too, that's the name of the trail.
>> 
>> Brad
>> 
>> On 12/29/22 08:59, Zeke Farwell wrote:
>>> I've heard the assertion that a way has no name but the route that passes 
>>> over it does many times.  While this is true in some cases, in others it is 
>>> not.  Where the primary purpose of the way is not for the route, this does 
>>> make sense.  For example mentioned by Jmapb where the Appalachian trail 
>>> follows an unnamed driveway or sidewalk.  In these cases, the primary 
>>> purpose is a driveway or sidewalk for local use, and the Appalachian Trail 
>>> just happens to follow it as well.  Here putting the name Appalachian Trail 
>>> on the way makes no sense.  However, there are also dedicated sections of 
>>> trail built first and foremost to be a part of the Appalachian Trail and 
>>> that have no other name.  Omitting the name Appalachian Trail in a case 
>>> like that makes no sense to me.  That section of trail is indeed called the 
>>> Appalachian Trail.  The whole route is also called the Appalachian Trail 
>>> and that's ok.
>>> 
>>> 
>>> On Thu, Dec 29, 2022 at 10:38 AM Jmapb  wrote:
>>> 
>>> On 12/29/2022 10:13 AM, Zeke Farwell wrote:
 Yes, the way name tag should be the most local trail name. 
 However, sometimes there is no local trail name and the long
 distance route name is the only name.  In this case putting the
 long distance route name on the ways also makes sense.
>>> 
>>> I've been doing some mapping on the Appalachian Trail lately and
>>> this appears to be the common practice, although the AT is
>>> dominant enough that constituent trails sometimes lose their
>>> local names over time.
>>> 
>>> Some mappers will take it a little too far and tag sections of
>>> sidewalk and driveway that the AT follows with name=Appalachian
>>> Trail (or even name=Appalachian National Scenic Trail... IMO this
>>> is an official_name, and probably only belongs on the route
>>> superrelation.)
>>> 
>>> It's common to see ref=AT as well, which is fine on trails (even
>>> locally named ones) and perhaps ok on the sidewalks, but adding
>>> it to a vehicular road seems iffy.
>>> 
>>> Jason
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>> 
>>> 
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names being applied to tracks/paths

[Yves via Tagging]

The simpliest way to map a long route is to give the same name to every ways it 
is composed of. Then, in second position, you can also create a relation.
Regards, 
Yves 


Le 29 décembre 2022 10:47:44 GMT+01:00, Warin <61sundow...@gmail.com> a écrit :
>Hi,
>
>It appears that route name are being applied to track/path names,
>
>I believe this comes about due to signs that state the route names and point 
>along the track/path that appear to the name of the track/path.
>
>For example Way 228853104 
>https://www.openstreetmap.org/way/228853104#map=15/37.8558/-107.3617
>
>Tagged as;
>
>name     Continental Divide NST {NST being an abbreviation of National Scenic 
>Trail}
>name_1     Colorado Trail (Segment 22)
>
>and part of relations;
>
>
>    Relation Colorado Trail (3445384)
>    Relation CDT ivc (8053592) {this is an abbreviation of Continental Divide 
>Trail and part of a relation, that is part of a relation, that is part of 
>Relation: Continental Divide National Scenic Trail (921198)!!!}
>
>I think the 'names' should be removed from these 'unnamed' things ..the 'name' 
>is the name of the route not the individual tracks/paths some of which existed 
>before some routes were created.
>
>Note I am not that familiar with the above 2 routes but am familiar with two 
>near me .. and those routes are relatively recent compared to the tracks and 
>paths they use.  I am useing those 2 routes as more people would be aware of 
>them than the ones I know.
>
>
>___
>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 - yarn shops

[Yves via Tagging]

I'm pretty sure this discussion already happened here years ago, did not found 
it, though.
Yves 

Le 2 janvier 2023 22:29:58 GMT+01:00, stevea  a 
écrit :
>Yes, sewing and knitting aren't all that related.  In California, we have what 
>are often known as "Vac-and-Sew" shops which sell (not necessarily all of) 
>vacuum cleaners and their supplies (hoses, attachments, nozzles, refill 
>bags...), sewing supplies and maybe sewing machines, sometimes fabric, 
>sometimes yarn and knitting supplies.  Some of them offer classes in these 
>endeavors, as well, in which case, they are more than a shop=*, they are a 
>sort of school=*.  (Or "artist-oriented classroom," like a pottery studio 
>which teaches how to use pottery wheels and might offer clay, glazes, other 
>related supplies and even kiln-space "rental").
>
>My point is that these are all different.  The long-standing OSM tenet of 
>"tag, tag well" (or "tag your best") continues to apply.  While I have all due 
>respect for wiki-authors who do great work of categorizing these things, at 
>best these can only be considered as guidelines, rather than hard-and-fast 
>tagging "requirements."  Yes, in OSM, (as "Street" is our middle name), in 
>some cases, as with motorways, a highway=motorway is a highway=motorway pretty 
>much the world over.  (Because we say so, we define what we mean by that).  
>With shops and art-related endeavors, there is much, much more variability, 
>and I doubt we'll ever reach consensus what "best" or "perfect" strategies 
>are.  So, the best we can do is continue to offer "tag your best" and "tag 
>well" as ongoing strategies.  Sure, discuss further if more can be "wrung out" 
>of such discussions, but realize that perfection may never be achieved.
>
>As long as "tag your best" and "one feature, one tag" continue, I think we're 
>in good shape.
>___
>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 - relation type=sled

[Yves via Tagging]

Why not https://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste ?
Sled is already documented and used for those relations.

Regards,
Yves 

Le 10 décembre 2022 10:11:39 GMT+01:00, Philipp Spitzer 
 a écrit :
>Dear all!
>
>I like to propose https://wiki.openstreetmap.org/wiki/Relations/Proposed/Sled 
>(which is actually a quite old proposal) which tries to overcome the 
>shortcomings of piste:type=sled (without replacing it).
>
>I would be happy if you could provide thoughts/comments in the corresponding 
>wiki page (preferred) or here.
>
>Thank you,
>Philipp
>
>___
>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 - relation type=sled

[Yves via Tagging]

I think it will be hard to find a lot of support for a relation type grouping 
sled runs, parking, restaurants, etc... 
All the additional features can be found easily in OSM: they are close to the 
run itself.

For the walking parts, highway=path or else, or maybe piste:type=hike or 
connection if nothing remains in summer are already walkable and routable to 
connect the sled run to the rest of the world.

In any case, this does not mean sledding doesn't deserve a nice documentation 
page in the wiki!

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

Re: [Tagging] Relations of type=site + tourism=camp_site

[Yves via Tagging]

Site relations are often used to models thing that aren't spatially joined, 
like windfarms, universities...
I can easily imagine it's reasonable to use them for campings in some corner 
cases where a single area doesn't work. 

Yves

Le 10 novembre 2022 12:11:44 GMT+01:00, Mateusz Konieczny via Tagging 
 a écrit :
>Yes, using site relation in addition to actual object breaks this rule
>and it is undesirable (and site relations in general are problematic).
>
>It would be also problem with type=site site=camp_sites and similar
>trying to hide duplication.
>
>Is there some reason why this camp sites cannot be mapped as areas
>if someone is doing such detailed mapping?
>
>or map operator of a toilet or extra features?
>
>
>Nov 9, 2022, 22:00 by li...@fuchsschwanzdomain.de:
>
>> Hello,
>>
>> about a year ago I implemented support for site relations in OpenCampingMap.
>>
>> My announcement from back then is at:
>> https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/
>>
>> Now a recent changeset discussion is questioning my whole approach because it
>> arguably violates the "One feature, one OSM element principle":
>>
>> https://www.openstreetmap.org/changeset/126035627
>>
>> Ignoring the principle (which is not absolute anyway) in this case and
>> adding a relation of type=site + tourism=camp_site containing the actual
>> tourism=camp_site object as a member does solve the problem thus I would go
>> for doing just this as I did a year ago.
>>
>> Obviously others seem to differ here.
>>
>> Currently the above changeset breaks my map regarding those campsites where
>> the tourism=camp_site tag has been removed from the site relation.
>>
>> External features are no longer shown :(
>>
>> So how to resolve this problem?
>>
>> campsites with external features (e.g.  sanitary facilities used by a
>> campsite and a sport-center) do exist in the wild and they usually do also
>> have on-the-ground objects (way, node, polygon-relation) where no other tag
>> than tourism=camp_site does make sense.
>>
>> What do you think?
>>
>> Sven
>>
>> ___
>> 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 of type=site + tourism=camp_site

[Yves via Tagging]

Good point Martin 

Le 10 novembre 2022 12:36:51 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 10 Nov 2022, at 12:31, Yves via Tagging  wrote:
>> 
>> Site relations are often used to models thing that aren't spatially joined, 
>> like windfarms, universities...
>> I can easily imagine it's reasonable to use them for campings in some corner 
>> cases where a single area doesn't work.
>
>
>multipolygons can solve any disjoint area problems, you only need a site 
>relation if some members are nodes or linear ways or relations. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Relations of type=site + tourism=camp_site

[Yves via Tagging]

Ah? 

Le 10 novembre 2022 21:09:47 GMT+01:00, Sven Geggus 
 a écrit :
>Yves  wrote:
>
>> Instead of type=site + tourism=camp_site, type=site + site=camp_site would
>> be less prone to objections, maybe.
>
>Well, wiki states that site=something is not recommended anymore. 
>
>Sven
>

How to map

Create a relation and add type=site. In addition, the relation must have a main 
tag defining whatever feature the site relation describes. E.g. 
amenity=university, site=parking, site=piste, power=plant, etc.


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

Re: [Tagging] Relations of type=site + tourism=camp_site

[Yves via Tagging]

Instead of type=site + tourism=camp_site, type=site + site=camp_site would be 
less prone to objections, maybe.


Regards,
Yves 

Le 9 novembre 2022 22:00:23 GMT+01:00, Sven Geggus 
 a écrit :
>Hello,
>
>about a year ago I implemented support for site relations in OpenCampingMap.
>
>My announcement from back then is at:
>https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/
>
>Now a recent changeset discussion is questioning my whole approach because it
>arguably violates the "One feature, one OSM element principle":
>
>https://www.openstreetmap.org/changeset/126035627
>
>Ignoring the principle (which is not absolute anyway) in this case and
>adding a relation of type=site + tourism=camp_site containing the actual
>tourism=camp_site object as a member does solve the problem thus I would go
>for doing just this as I did a year ago.
>
>Obviously others seem to differ here.
>
>Currently the above changeset breaks my map regarding those campsites where
>the tourism=camp_site tag has been removed from the site relation.
>
>External features are no longer shown :(
>
>So how to resolve this problem?
>
>campsites with external features (e.g.  sanitary facilities used by a
>campsite and a sport-center) do exist in the wild and they usually do also
>have on-the-ground objects (way, node, polygon-relation) where no other tag
>than tourism=camp_site does make sense.
>
>What do you think?
>
>Sven
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Yves via Tagging]

Exactly, one have to keep in mind you are lucky if stuff get updated in OSM 
more frequently than once every  a few years.
Yves 

Le 8 août 2023 19:11:25 GMT+02:00, Florian Lohoff  a écrit :
>On Sun, Aug 06, 2023 at 07:18:29PM +, NickKatchur via Tagging wrote:
>> Hello,
>> 
>> I have developed a proposal to indicate the availability of cell phone
>> service at nodes and areas,
>> https://wiki.openstreetmap.org/wiki/Proposal:Cell_reception.
>
>I would consider this data much to volatile to make sense in OSM.
>Cellphone Networks are constantly changing, frequencies, modulation,
>coverage, sector antennas are replaced constantly. So GSM may fade out,
>LTE comes in. Different frequency, different coverage.
>
>Flo
>-- 
>Florian Lohoff f...@zz.de
>  Any sufficiently advanced technology is indistinguishable from magic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for wheelchair users

[Yves via Tagging]

Le 14 mai 2023 17:15:33 GMT+02:00, Tobias Knerr  a écrit :
>On 13.05.23 at 18:28 Marc_marc wrote:
>> why not just add this information as amenity=parking_space geometry ?
>
>Indeed, amenity=parking_space is usually mapped as a polygon (over 94% of 
>amenity=parking_space tags are on ways, according to Taginfo). This makes it 
>possible to determine the dimensions with relatively simple calculations and 
>it seems undesirable to duplicate this information as tags.
>
These two suggestions made me laugh a bit: everybody is not super accurate in 
drawing polygons, imagery has a resolution and I doubt a lot of mappers go 
trough a complete parking lot a measuring tape in their hands. 
On the contrary, estimating a width from one's car when you happen to really 
need to know is probably not far-fetched. 
I'd say yes to such a tag. 
Regards, 
Yves 

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

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for wheelchair users

[Yves via Tagging]

I guess that if I'd want to inform my user about a parking space width, I'll 
stick to a specific width=* tag, and not rely on a hundredth "good enough" 
polygon geometry mapped at 3 in the morning.
At least I'm sure that if the mapper care enough to estimate a width, it's not 
completely wrong.

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

Re: [Tagging] tagging "loose" paving stones

[Yves via Tagging]

Out of curiosity, I looked the Web for wiggly pavement for drainage. Somme 
pavement have extra tips on the side for increased spacing. 
Apparently, as long as it's built on sand, the drainage is pretty good, no 
mention of a loose setup.
Maybe the politician is very good at his job? ;-)
Yves 

Le 21 février 2024 12:25:39 GMT+01:00, Anne-Karoline Distel via Tagging 
 a écrit :
>Hi,
>
>yes, I think paving_stones is right, but I'm fairly convinced that it
>was built wiggly on purpose, otherwise the politician wouldn't have had
>a special word for it. I couldn't find anything on wikipedia about the
>topic, unfortunately.
>
>Cycling across is not a problem, if you don't mind the sound. I don't
>think the whole width of the street is paved wiggly, just enough to let
>the water drain, so skaters could use it on the sides.
>
>I wasn't too concerned about the mapping for traffic users of the
>street, more for flood prevention analysis, but maybe that's just not
>within the scope yet.
>
>Anne
>
>On 21/02/2024 09:50, Mateusz Konieczny via Tagging wrote:
>> I also would go with surface=paving_stones - and maybe add also
>> smoothness tag,
>> and agree with Fernando
>> 
>> 
>> Feb 21, 2024, 01:47 by fernando.treb...@gmail.com:
>> 
>> I think they are surface=paving_stones because:
>> - the stones are very flat on top
>> - it seems that the objective was to arrange them snugly, although
>> the fit may have deteriorated a little
>> - it seems pretty easy to ride a bike there, but not skate, which
>> is what one generally expects from surface=paving_stones;
>> surface=sett is a little more difficult for cycling because the
>> stones are less flat and the surface as a whole is also less flat
>> 
>> I think surface=sett is usually more like this:
>> 
>> https://www.mapillary.com/app/?lat=53.345215550023994=-6.265817519990492=19.230259053537715=516305962724410=photo=0.5077006613416395=0.584942612357=0
>> 
>> 
>> 
>> On Sat, 17 Feb 2024 at 15:55, Anne-Karoline Distel via Tagging
>>  wrote:
>> 
>> 
>> That's the best I can do for now:
>> 
>> https://www.mapillary.com/app/?lat=52.65192667=-7.251596667=17=1685817985195902=photo=0.22772882642716127=0.968169011381621=0
>> 
>> 
>> You can kind of see the gaps between the stones.
>> 
>> On 17/02/2024 17:46, Åbn wrote:
>>> I think you should provide a picture.
>>> 
>>> 
>>> On February 17, 2024 5:19:06 PM UTC, Anne-Karoline Distel via
>>> Tagging 
>>>  wrote:
>>> 
>>> I'm not sure I'm understanding the differences between
>>> surface=sett and surface=paved or if what I'm trying to
>>> map is covered by either. Where I live, there are some
>>> streets that are paved, but the stones aren't set firmly,
>>> so they wobble a bit when you drive/ cycle over them. It
>>> is perfectly safe, but it allows rainwater to drain
>>> quicker, at least I think that is the reason for this
>>> type of paving. It sounds a bit like a xylophone (well,
>>> lithophone, I guess), when going over them. Considering
>>> climate change and the higher likelihood of flooding etc,
>>> it would be important to map the difference between paved
>>> streets that don't allow for quick drainage and these
>>> loosely paved streets. There is probably some technical
>>> term for it. So, in short: Do we have a tagging scheme
>>> for those or not? Anne
>>> 
>>> 
>>> Tagging mailing list Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>> 
>> 
>> --
>> Fernando Trebien
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging "loose" paving stones

[Yves via Tagging]

Surface=Paved is generic. Maybe you're talking about cobblestone?


Le 17 février 2024 18:19:06 GMT+01:00, Anne-Karoline Distel via Tagging 
 a écrit :
>I'm not sure I'm understanding the differences between surface=sett and
>surface=paved or if what I'm trying to map is covered by either. Where I
>live, there are some streets that are paved, but the stones aren't set
>firmly, so they wobble a bit when you drive/ cycle over them. It is
>perfectly safe, but it allows rainwater to drain quicker, at least I
>think that is the reason for this type of paving. It sounds a bit like a
>xylophone (well, lithophone, I guess), when going over them.
>
>Considering climate change and the higher likelihood of flooding etc, it
>would be important to map the difference between paved streets that
>don't allow for quick drainage and these loosely paved streets. There is
>probably some technical term for it.
>
>So, in short: Do we have a tagging scheme for those or not?
>
>
>Anne
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging "loose" paving stones

[Yves via Tagging]

Interesting, this could also be used to let water in the ground in order not to 
cause subsidence by drying out the underground. Maybe we shouldn't map the 
intent, but be more descriptive. 
Technically, it is possibly just sett, but loose? 
Yves 

Le 17 février 2024 22:59:08 GMT+01:00, Anne-Karoline Distel via Tagging 
 a écrit :
>I asked a local Green politician, and it's apparently called "subsidence
>paving",  invented in earthquake zones in northern Italy.
>
>On 17/02/2024 17:46, Åbn wrote:
>> I think you should provide a picture.
>> 
>> 
>> On February 17, 2024 5:19:06 PM UTC, Anne-Karoline Distel via Tagging
>>  wrote:
>> 
>> I'm not sure I'm understanding the differences between
>> surface=sett and surface=paved or if what I'm trying to map is
>> covered by either. Where I live, there are some streets that are
>> paved, but the stones aren't set firmly, so they wobble a bit when
>> you drive/ cycle over them. It is perfectly safe, but it allows
>> rainwater to drain quicker, at least I think that is the reason
>> for this type of paving. It sounds a bit like a xylophone (well,
>> lithophone, I guess), when going over them. Considering climate
>> change and the higher likelihood of flooding etc, it would be
>> important to map the difference between paved streets that don't
>> allow for quick drainage and these loosely paved streets. There is
>> probably some technical term for it. So, in short: Do we have a
>> tagging scheme for those or not? Anne
>> 
>> 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] shops for display

[Yves via Tagging]

Showroom... It's not a room either, usually the public can't enter the 
prémices, just have a look through the window.
Yves 

Le 21 novembre 2023 12:40:51 GMT+01:00, Niels Elgaard Larsen  
a écrit :
>On Tue, 21 Nov 2023 08:00:53 +0100 (CET)
>Mateusz Konieczny via Tagging  wrote:
>
>>advertising=display_window works much better than shop=display_only
>>(as it is not a shop)
>
>
>Yes, if it is a vacant shop.
>
>>though maybe there is value with more immediately clear meaning?
>
>
>
>The wiki for Tesla says that Tesla showrooms are tagged shop=car
>A lot of shop=kitchen are really showrooms where you can order a
>kitchen which will be installed in you kitchen. The shop do not actually
>have kitchens for sale in the store.
>
>There are more that 100 "showroom" tags in OSM.
>Maybe we could use showroom=only for shops that are only showrooms.
>
>
>
>>Nov 20, 2023, 21:37 by 1998alexk...@gmail.com:
>>
>>>
>>> Sounds like something like "advertising=display_window" or similar
>>> would make more sense
>>>
>>>
>>> Alex
>>>
>>>
>>> On Mon, Nov 20, 2023, 21:29 Martin Koppenhoefer <>
>>> dieterdre...@gmail.com> > wrote: 


 sent from a phone

  > On 20 Nov 2023, at 20:59, Anne-Karoline Distel <>>
  > annekadis...@web.de>> > wrote:
  > 
  > Hi,
  > 
  > is there a way to tag shops that are not used for selling goods
  > directly, but are just used for display for the actual shop or
  > even to advertise something different? Here in Ireland, I think
  > they are often used to hide the fact that it's actually a vacant
  > premises, and rates are also different, I believe, if you're not
  > actually conducting business there. Would "shop=display_only" be
  > a way to do it? I would still like to have an option to mark
  > them as vacant,  in a way.
  > 
  > They could be using the space inside to display their goods or
  > even just have the windows covered in decals to advertise that
  > they have moved or to advertise local sights or whatever.  
  
  
  according to the wiki a shop is selling goods or services, if they
 don’t do either it’s not a shop for OpenStreetMap. 
  Cheers Martin 
  ___
  Tagging mailing list  
  >> Tagging@openstreetmap.org
  >> https://lists.openstreetmap.org/listinfo/tagging  
  
>>
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging