Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-21 Thread Mateusz Konieczny via Tagging



Dec 21, 2020, 16:42 by zelonew...@gmail.com:

>
>
> On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm <> frede...@remote.org> > wrote:
>  
>
>> Our current data model is not suitable for mapping fuzzy areas. We can
>>  only do "precise". Also, as you correctly pointed out, or basic tenet of
>>  verifiability doesn't work well with fuzzy data.
>>
>
> The current data model works just fine for fuzzy areas: it requires a polygon 
> combined with tagging that indicates that the area is "fuzzy".  Since the 
> current data model allows both polygons and tags, fuzzy areas could be mapped 
> just fine from a technical standpoint.
>
Bigger problem is that with things like mountain ranges there are multiple 
differing opinions
about borders.

For example in case of https://pl.wikipedia.org/wiki/Beskid_Wyspowy multiple 
authors
give precise, unfuzzy borders (specific rivers or roads).

But different authors prefer different borders.

See for example https://en.wikipedia.org/wiki/Borders_of_the_oceans
and https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth
for other kind of differences. Modelling this is not fitting well how OSM works.


>
>
>> So the one questions is, do we want fuzzy areas, the other is, if we
>>  want them, how can they be established - because in our current database
>>  they cannot.
>>  
>>  I think fuzzy areas make a lot of sense for cartography, but I strongly
>>  object to people adding hand-wavy polygons to OSM for fuzzy areas.
>>
>
> "Whether we want fuzzy areas" and "how they can be established" is certainly 
> an open question that requires additional intellectual thought and 
> consensus-building to achieve.  However, the statement that they "cannot" be 
> established in our database is simply an opinion, not a technical barrier.
>
I would not say cannot, but it is extremely poor fit to OSM data model and how
OSM operates.

> The statement that fuzzy polygons is "damaging" is an argument not based in 
> fact.  It is not damaging to me to have building outlines, which I do not 
> care about.  I can simply ignore them.  Likewise, fuzzy areas cause no damage 
> to people that do not care about fuzzy areas, provided that there is tagging 
> that distinguishes them from non-fuzzy areas.
>
It is not so easy. Someone mapped several fuzzy areas in my regions and all of
them are extremely irritating while mapping.

Building outlines are not stretching for hundreds of kilometers and do
not appear in places where there is nothing at all and building outlines
are verifiable unlike mess like https://www.openstreetmap.org/relation/1757627
and other from https://overpass-turbo.eu/s/11pc

Some day I will need to check whatever it is also one big copyright violation
(for now I just left questions at ancient changesets that added this mess).

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


Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

2020-12-21 Thread Mateusz Konieczny via Tagging
I like this new tag.

I had proposing something like that on my TODO list.

I added it in https://www.openstreetmap.org/changeset/96211869 

to mark addr:housenumber=1-3 as a single address, not a range
(based on survey that I remember well)

Dec 21, 2020, 19:05 by tagging@openstreetmap.org:

> Okay. In this case I can rename to proposal page to "addr:range".
>
> This new tag:
>
> - applies to nodes and closed ways that have addr:housenumber
> - "addr:range=n" means every nth house is counted in a range
> - "addr:range=even/odd" means every even/odd house is counted
> - "addr:range=all" means every house is counted (default value for a 
> housenumber tag with a hyphen in it if no range is given).
> - "addr:range=no" means that the housenumber tag is NOT a range of values but 
> rather a single housenumber.
>
> "addr:range=all" is the default  because that is what the wiki says and what 
> software like streetcomplete suggests. Many buildings with multiple 
> housenumbers are tagged like this.
>
> However, software can create different defaults for different countries. For 
> example, in the UK a hypenated address most probably means a range of 
> even/odd addresses (so "addr:range=2")
>
> What are your thoughts on this?
>
> Also, I had linked the talk-gb thread, which discusses how addr:interpolation 
> on closed ways and nodes is already standard. That is the problem with 
> suggesting a new tag. This proposal would now require informing multiple 
> mappers to switch up the taggong scheme.
>
> Thanks,
> IpswichMapper
>
> -- 
>
>
> 21 Dec 2020, 15:19 by lon...@denofr.de:
>
>> On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging wrote:
>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
>>>
>>> Quick proposal I just created to accept this form of tagging. This follows 
>>> from a discussion on the Talk-GB mailing list.
>>>
>>> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
>>>
>>>
>>> Please comment if there are issues with accepting this form of tagging.
>>>
>>
>> I dislike this kind of tagging to the point that I've refused to
>> support it in Nominatim in the past. See
>> https://github.com/osm-search/Nominatim/issues/565 for the full disucssion.
>>
>> The problem is that it makes the interpretation of addr:housenumber and
>> addr:interpolation dependent on the presence of another tag.
>>
>> Note that addr:housenumber=40-48 can be a valid housenumber. Example:
>> https://www.openstreetmap.org/way/285077586 So to know if the tag needs
>> to be interpreted as a single housenumber or as a housenumber range
>> you need to check if the node/way has a addr:interpolation tag in addtion
>> to the addr:housenumber tag.
>>
>> Similarly, a way with addr:interpolation needs to be processed in two
>> different ways: If a addr:housenumber is present, then assume it's a
>> building and parse the addr:housenumber tag to get the range. If no
>> housenumber is on the way, assume it is a good old interpolation line
>> and look at the housenumbers along the nodes of the way.
>>
>> I find this kind of double meaning for tagging confusing and error-prone.
>> But I might be fighting wind mills here.
>>
>> Sarah
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>

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


Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

2020-12-21 Thread Mateusz Konieczny via Tagging
Dec 20, 2020, 23:29 by graemefi...@gmail.com:

> On Sun, 20 Dec 2020 at 17:55, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>> How objects tagged now with amenity=lifeboat_station should be tagged after 
>> this proposal passes?
>>
>
> They were a late addition after somebody pointed out that they exist. They 
> would be replaced by emergency=marine_rescue, which has already been defined 
> as groups " dedicated to the rescue of vessels &/or sailors at sea"
>
The problem is that some water rescue stations are not marine but inland.

>>
>> Also "The area of the Rescue base should render with the same pink colour as 
>> currently used for
>> Police & Fire Stations, together with an "SOS" icon." is problematic as 
>> proposal process has no
>> power to select any rendering in any map style.
>>
>
> Yes, but all proposals suggest a rendering scheme.
>
Suggesting rendering is OK. But "should render with the same pink colour as 
currently used for"
reads like instruction that render is supposed to follow - while it is not 
working this way.

Also, not all of them 
(see for example 
https://wiki.openstreetmap.org/wiki/Proposed_features/carpet_hanger
where I skipped this section) 

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


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-21 Thread Mateusz Konieczny via Tagging



Dec 21, 2020, 13:01 by dieterdre...@gmail.com:

> Am Mo., 21. Dez. 2020 um 08:40 Uhr schrieb Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>>
>> Mapping military bases in Israel, Russia, mapping anything in China/North 
>> Korea
>> etc should be welcomed in OSM if someone is doing this and wants that.
>>
>
>
>
> Mateusz, this is a quite detailed list, can you explain which other countries 
> are included in "etc"? I do not know about Israel, Russia or North Korea, but 
> I am pretty sure that mapping in China is illegal.
>
Yes, mapping China without explicit permission breaks Chinese law.
But it is not against OSM rules to be within Chinese jurisdiction and map China.

The same for mapping military bases in Russia or Israel.

'can you explain which other countries are included in "etc"' - I heard about 
other countries
that have similar laws but I have not verified this claims.

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


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-20 Thread Mateusz Konieczny via Tagging



Dec 21, 2020, 08:18 by graemefi...@gmail.com:

>
> Thanks
>
> Graeme
>
>
> On Mon, 21 Dec 2020 at 16:44, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>> OSMF board is not spending hours on monitoring wiki pages.
>>
>> I am spending hours on monitoring wiki pages and noticed it only recently,
>> and only in a new proposal.
>>
>> Anyone may edit Wiki and many things are present there because noone
>> noticed what is written somewhere.
>>
>>> Somebody obviously considers that they should be noted there?
>>>
>> I am not against noting legal restrictions in some countries that may be 
>> dangerous for some mappers. But I am against implying that it is 
>> against OSM rules to map in China or map military bases in Russia/Israel/etc
>> or that it is unwanted.
>>
>
> The suggestion was made to me privately that this matter be raised via the 
> Legals list to get an official opinion or ruling, & if it is agreed that it 
> is a requirement, hopefully also an agreed wording for a "warning".
>
> I agree that that is probably the best option, but also consider that it 
> could be left until after the proposal is accepted or not, &, once again, it 
> would be done as part of a clean-up of the military pages.
>

At least I will vote against proposal that includes
"As always, if it is illegal in your country to map military establishments, 
please do not do so!".

I will certainly not demand breaking such law, or expect people to risk it. 
Especially
as such law is often present in countries where going against government is
especially risky.

But implying that it is also against OSM rules is not acceptable to me.

Mapping military bases in Israel, Russia, mapping anything in China/North Korea
etc should be welcomed in OSM if someone is doing this and wants that.

Though making people aware about risks is a  good idea.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposed feature - RFC - Military Bases

2020-12-20 Thread Mateusz Konieczny via Tagging



Dec 21, 2020, 01:43 by graemefi...@gmail.com:

>
>
>
>
> On Mon, 21 Dec 2020 at 10:37, Martin Koppenhoefer <> dieterdre...@gmail.com> 
> > wrote:
>
>>
>> imagine you were mapping something, and it is legal in the place where you 
>> are, but illegal in Britain, so you can not do it. Or you are seeing things 
>> in country A and when you’re in country B you add them to OpenStreetMap 
>> (from memory), which is legal in country B but not in country A. You might 
>> be able to do it and still be arrested when going back to country A.
>>  
>>  People also said in the past we should adhere to European law because 
>> otherwise our dataset can not be used in the EU (e.g. with respect to 
>> copyright and fair use). I am not sure if after the Brexit this will still 
>> be the OpenStreetMap-Foundation policy, or whether they focus completely on 
>> British law, but I am sure that Chinese law has not been deemed relevant by 
>> past and present osmf boards.
>>
>
> I agree it's incredibly confusing, & a legal minefield (as well as 
> potentially a real one!), but if it's an issue, why haven't the "Warnings" 
> been deleted from the various military pages prior to this?
>
OSMF board is not spending hours on monitoring wiki pages.

I am spending hours on monitoring wiki pages and noticed it only recently,
and only in a new proposal.

Anyone may edit Wiki and many things are present there because noone
noticed what is written somewhere.

> Somebody obviously considers that they should be noted there?
>
I am not against noting legal restrictions in some countries that may be 
dangerous for some mappers. But I am against implying that it is 
against OSM rules to map in China or map military bases in Russia/Israel/etc
or that it is unwanted.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

2020-12-19 Thread Mateusz Konieczny via Tagging

How objects tagged now with amenity=lifeboat_station should be tagged after 
this proposal passes?

It deprecates some tags without info about proposed replacements about any of 
them,
and some are actually used.

Also "The area of the Rescue base should render with the same pink colour as 
currently used for
Police & Fire Stations, together with an "SOS" icon." is problematic as 
proposal process has no
power to select any rendering in any map style.

And in many renderers different (or none) styling is used for rendering this 
object anyway.

Dec 20, 2020, 04:31 by graemefi...@gmail.com:

>
>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick <> graemefi...@gmail.com> > 
> wrote:
>
>> https://wiki.openstreetmap.org/wiki/Rescue_Stations>>  
>>
>
> Moved to voting.
>
> If you still have any comments or concerns, please raise them for discussion, 
> rather than just voting "No, because ..."! 
>
> Thanks
>
> Graeme
>

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


Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Mateusz Konieczny via Tagging



Dec 20, 2020, 00:01 by 61sundow...@gmail.com:

> On 20/12/20 6:45 am, Mateusz Konieczny via Tagging wrote:
>
>> Is there some good use for sport=shooting_range?
>>
>> Or is it always preferable to use sport=shooting + leisure=pitch?
>>
>> This is a request to review this edit
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Asport%3Dshooting_range=revision=2074293=125712
>> that ended creating 
>> https://wiki.openstreetmap.org/wiki/Tag:sport%3Dshooting_range
>>
>
> The sport key should be used to indicate the activity .. not the physical 
> existence. Despite what the OSMwiki says though various edits.
>
Where OSM Wiki claims that sport key alone indicates physical existence of 
something?
As far as I know it only describes that it specifies type/purpose of something 
like
leisure=pitch.

> The physical presence is give by some other key, such as 
> landuse=recreation_ground, pitch, etc...
>
>

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


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

2020-12-19 Thread Mateusz Konieczny via Tagging



Dec 20, 2020, 01:18 by pla16...@gmail.com:

> On Sat, 19 Dec 2020 at 23:58, <> 80hnhtv4a...@bk.ru> > wrote:
>
>> it had the word bump in it.
>>
>
> Yes, it had the word "bump" in it.  "Bump" is an English word.  There
> are traffic-calming devices with the word "bump" in their name.
>
> The proposal talks of "bumbs."  "Bumb" is not an English word.  I
> cannot find any traffic-calming device with "bumb" in their name.
>
> It's bumP versus bumB.  One is a word.  The other is not a word
> but is in the proposal.  Twice.
>
I assumed that it is typo and changed bumb to bump

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


[Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Mateusz Konieczny via Tagging
Is there some good use for sport=shooting_range?

Or is it always preferable to use sport=shooting + leisure=pitch?

This is a request to review this edit
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Asport%3Dshooting_range=revision=2074293=125712
that ended creating 
https://wiki.openstreetmap.org/wiki/Tag:sport%3Dshooting_range
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-19 Thread Mateusz Konieczny via Tagging
Thanks for documenting this new value!

I edited page in attempt to provide more specific definition
(based on photos).

To author of a proposal: feel free to revert my edit or change it
or do something else with it

I wonder whatever there is even a British English name for that
(or is hillocky an UK name?)
Dec 19, 2020, 19:23 by thur...@gmail.com:

>
> Hi,
>
>
>   I would like introduce traffic calming device not present in the list of 
> devices.
>
>
>
> Definition: A traffic calming device with specific qualities
>
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%3Dhillocky>
>   
>
>
>
>
> Regards,
>
>
> Tomas Huryn
>
>

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


Re: [Tagging] addr:floor and level:ref - Wiki review welcomed

2020-12-18 Thread Mateusz Konieczny via Tagging
Dec 18, 2020, 17:44 by si...@poole.ch:

>
> addr:floor is an address tag and used in -(postal)-addresses-  when the 
> floor is customarily or required to be included.
>
>
> level:ref is a SIT tag used to indicate the name (or other  numbering) of 
> a level contrary to the zero based number of the  level tag.
>
>
> While both level:ref and addr:floor can have the same value,  
> semantically they are different
>
>
Thanks for clarification! Though as far as I know in practice level tag in some 
regions is used
with 1 assigned to ground floor (I am not sure whatever to consider this as a 
tagging mistake 
or not).

> replacing level:ref with  addr:floor which is what you were suggesting 
> with what boils down  to a mechanical edit with SC, will break SIT tagged 
> buildings.
>
To be clear, I was not suggesting replacing either tag with another.

And if https://github.com/streetcomplete/StreetComplete/issues/1487
would be implemented it would be adding new tags to objects where
level tag is tagged. It would not be "upgrade tags" wikifiddling.

 if I would implementit it would not delete any existing ones.
Objects tagged already with level:ref or addr:floor or level would be skipped
and this quest would not apply to them.
In this case resurvey with StreetComplete is pointless
(unlike case of opening hours), objects such as shops in general do
not move between floors while keeping their lat/lon position.

Am 18.12.2020 um 14:01 schrieb Mateusz  Konieczny via Tagging:

>> 1) this edits were not intended as changing anything but to  
>> document current tagging
>> practice
>>
>> 2) how Simple Indoor Tagging is being broken by either of  this tags?
>>
>> 3) If SIT is broken by that tags, how it can be avoided?  
>> Recommending to use 
>> level tag together with either of this two?
>>
>>
>> Dec 18, 2020, 13:34 by >> si...@poole.ch>> :
>>
>>>
>>> This doesn't make any sense outside of trying breaking the  SIT 
>>> tagging scheme If you have changes to suggest do that in  the 
>>> context of  an SIT improvement and not just so that you  can add 
>>> yet another SC challenge.
>>>
>>> Am 18.12.2020 um 13:11 schrieb Mateusz Konieczny  via Tagging:
>>>
>>>> I heavily edited >>>> https://wiki.openstreetmap.org/wiki/Key:addr:floor
>>>> and created >>>> https://wiki.openstreetmap.org/wiki/Key:level:ref
>>>>
>>>> Please, edit this pages if something can be improved.
>>>>
>>>> Review of this pages also would be welcomed.
>>>>
>>>> (edits triggered by >>>> 
>>>> https://github.com/streetcomplete/StreetComplete/issues/1487
>>>> and done as part of survey of a tagging situation beforea 
>>>> potential implementation)
>>>>
>>>> ___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] addr:floor and level:ref - Wiki review welcomed

2020-12-18 Thread Mateusz Konieczny via Tagging



Dec 18, 2020, 14:56 by dieterdre...@gmail.com:

> Am Fr., 18. Dez. 2020 um 14:07 Uhr schrieb Mateusz Konieczny <> 
> matkoni...@tutanota.com> >:
>
>>
>> 4) I am not planning to work on deprecating either one
>>
>
>
> but you are working on cosolidating _both_
>
No, I just researched and described current state. What is needed anyway before 
any sort 
of meaningful deprecation discussion.


> "level:ref" could be described as a possible duplicate of addr:floor 
> introduced through
> undiscussed massedits or imports
>
This would require further research, to locate them - maybe this edits/imports 
were discussed.

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


Re: [Tagging] addr:floor and level:ref - Wiki review welcomed

2020-12-18 Thread Mateusz Konieczny via Tagging
1) both are in use and while level:ref has more uses most of them come from 
mass edits[1]

2) this edits were intended to document current tagging practice, not to create 
a proposal

3) addr:floor went through a proposal[2] and I am not going to mark it as 
deprecated
without consultation

4) I am not planning to work on deprecating either one

5) I am not aware about any subtle differences except what was mentioned at 
wiki page 
(tagging trash can with level:ref seems reasonable, tagging trash can with 
addr:floor seems
weird, similar with other tags not carrying addresses)

6) If someone wants to make a proposal related to this tags (including 
deprecations)
- feel free, I am not planning to do this

[1] note spikes in usage count at 
https://taginfo.openstreetmap.org/keys/level%3Aref#chronology
indicating large numbers of tags added in very short time, with barely any use 
otherwise -
typical for imports and mass retaggings
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/addr_keys_(2011-04)


Dec 18, 2020, 13:35 by dieterdre...@gmail.com:

> Your edit makes sense, at least as a first step, but we should reflect how to 
> explain why addr:floor is described as an alternative to level:ref, and not 
> as a "possible tagging mistake". Are there subtle differences? If not, I 
> would prefer to choose one and discourage the other. 10.000 uses are not 
> completely ignorable, but they still indicate this is in the beginning, given 
> that we have millions of POIs.
>
> Cheers
> Martin
>

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


Re: [Tagging] addr:floor and level:ref - Wiki review welcomed

2020-12-18 Thread Mateusz Konieczny via Tagging
1) this edits were not intended as changing anything but to document current 
tagging
practice

2) how Simple Indoor Tagging is being broken by either of this tags?

3) If SIT is broken by that tags, how it can be avoided? Recommending to use 
level tag together with either of this two?


Dec 18, 2020, 13:34 by si...@poole.ch:

>
> This doesn't make any sense outside of trying breaking the SIT  tagging 
> scheme If you have changes to suggest do that in the  context of  an SIT 
> improvement and not just so that you can add  yet another SC challenge.
>
> Am 18.12.2020 um 13:11 schrieb Mateusz  Konieczny via Tagging:
>
>> I heavily edited >> https://wiki.openstreetmap.org/wiki/Key:addr:floor
>> and created >> https://wiki.openstreetmap.org/wiki/Key:level:ref
>>
>> Please, edit this pages if something can be improved.
>>
>> Review of this pages also would be welcomed.
>>
>> (edits triggered by >> 
>> https://github.com/streetcomplete/StreetComplete/issues/1487
>> and done as part of survey of a tagging situation before apotential 
>> implementation)
>>
>> ___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] addr:floor and level:ref - Wiki review welcomed

2020-12-18 Thread Mateusz Konieczny via Tagging
I heavily edited https://wiki.openstreetmap.org/wiki/Key:addr:floor
and created https://wiki.openstreetmap.org/wiki/Key:level:ref

Please, edit this pages if something can be improved.

Review of this pages also would be welcomed.

(edits triggered by https://github.com/streetcomplete/StreetComplete/issues/1487
and done as part of survey of a tagging situation before a potential 
implementation)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-17 Thread Mateusz Konieczny via Tagging



Dec 17, 2020, 08:02 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 16. Dec 2020, at 17:52, Joseph Eisenberg  
>> wrote:
>>
>> You still have to distinguish marine water (outside of the 
>> natural=coastline) from inland waters, and distinguishing rivers from lakes 
>> is very important for proper rendering of many maps.
>>
>
>
> and it seems landuse=reservoir is used for sewage as well:
> https://taginfo.openstreetmap.org/tags/reservoir_type=sewage
>
> is this appropriate for natural=water?
>
No.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:

> The last time I looked, there was no non-deprecated way to map the 
> information that I had.
>
That is sign of bad tagging scheme.

> I now see that @jeisenbe has restored the `waterway=rapids` tag to the Wiki.  
>
Is it enough?

> I asked here on the mailing list, and the only answers that I got were along 
> the lines of "then don't map it."  So for several years I haven't attempted 
> to map rapids. The ones I know of and want to render, I maintain separately 
> from OSM, because the previous discussion had caused me to label this feature 
> mentally as, "OSM doesn't want this mapped."
>
:( Hopefully this can be fixed so this will not happen.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging
Dec 16, 2020, 16:49 by tomasstrau...@gmail.com:

> 2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
>
>> I agree that it is useful only for primitive rendering of water areas
>> (that possibly filters water areas by area but does not distinguish
>> between lakes and rivers). It may be worth mentioning.
>>
>> But it is also the most typical and common way of rendering things.
>>
>
> How do you decide that it is most typical and common way of rendering things?
>  ALL maps I created or seen in GIS/Cartography world, be it online or
> printed, interpret water classes differently, especially
> basins/riverbanks... 
>
Then I can you show some map style that do it differently and 
render all types of water areas in the same way (some 
render also labels in the same way, with exception
for linear features)

https://www.openstreetmap.org/#map=14/54.3643/18.7150
https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
https://www.openstreetmap.org/#map=14/54.3666/18.7138=H 
<https://www.openstreetmap.org/#map=14/54.3666/18.7138=T>

In contrast
https://www.openstreetmap.org/#map=14/54.3666/18.7138=O 
<https://www.openstreetmap.org/#map=14/54.3666/18.7138=T>
appears to distinguish seas/oceans


> Best system is to use codes, not names for keys/values, but that is a
> totally different "saga".
>
Feel free to propose this one.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Mateusz Konieczny via Tagging
OSM Wiki is "dedicated wiki that documents current practices"

Yes, it is sometimes outdated - but it is unlikely to be changed by creating an 
exact duplicate.

If you see something wrong you are welcome to edit it (feel free to ask for help
if you need it).

Dec 16, 2020, 16:49 by o...@dead10ck.com:

> Right, this is what I was thinking as well, it makes a lot of sense to have 
> the direction that's on the sign post to aid with navigation. It seems a 
> dedicated wiki that documents current practices would be helpful. Thank you!
> -- 
> Skyler
>
> On Wed, 2020-12-16 at 16:33 +0100, Tom Pfeifer wrote:
>
>> On 16.12.2020 14:19, Skyler Hawthorne wrote:
>>
>>>
>>> On Wed, Dec 16, 2020, at 05:44, Tom Pfeifer wrote:
>>>
 What is written on the sign at this junction? If "North" is mentioned 
 there I would be
 happy enough with the tagging above.

>>>
>>> That is correct, the sign says "I 787 North". However the wiki page for the 
>>> destination:ref key states:
>>>
>>> The key destination:ref <
>>> https://wiki.openstreetmap.org/wiki/Key:destination:ref>=*
>>>  should be
>>> used to specify the reference of the roads directly ahead as indicated 
>>> on signposts, road
>>> markings or similar. The value of this key should be equal to the value 
>>> of the key ref
>>> <
>>> https://wiki.openstreetmap.org/wiki/Key:ref>=*
>>>  of these roads.
>>>
>>> Note the last sentence. If the destination:ref must be the same as the ref 
>>> it is going to, then this 
>>> would be I 787, or else all the ways along the entire I 787 route should 
>>> have their ref tags changed 
>>> to indicate direction as well.
>>>
>>
>> Well, it says 'should', not 'must', thus in this case using 
>> destination:ref="I 787 North" is a 
>> refinement of just "I 787". Maybe an improvement for the phrase in the wiki 
>> would be
>> "should be equal to or a further qualification of related to the value...".
>>
>> On 16.12.2020 15:41, Paul Johnson wrote:
>>  > Wouldn't it make more sense, and isn't it already more common, for 
>> destination tags to contain the
>>  > information on the destination signs, which /do/ differentiate direction?
>>
>> Haven't analysed that, but if the destinations are signposted that way, it 
>> should be reflected in
>> the tagging.
>>
>>  > I feel like this is another example of "the wiki was written by someone 
>> with inadequate information."
>>
>> Both tagging and wiki develop, hopefully forward. In this case, 
>> Key:destination:ref redirects
>> onto an old 2012 proposal, I'm probably going to resolve that soon with 
>> describing the current practice.
>>
>>   tom
>>
>>
>> ___
>> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 15:22 by tomasstrau...@gmail.com:

> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>
>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>> (just added)
>>
>
> Thank you. Maybe it is better to discuss here before adding to wiki?
>  
>
In my experience it results just in not adding anything at all.

It is wiki and can be edited by anyone, so if what I added is wrong it can be 
changed.

>
>
> My arguments on the points you've added:
>
>  1. Regarding benefit of having a combining level/tag natural=water.
> If today you would query all data with natural=water - you will get
> not only lakes and reservoirs grouped, but also riverbank polygons
> (totally different beast) and micro elements like water=pond. This
> could only be partly useful in the largest scale maps and only if you
> make very simple maps and for some reason use the same symbolisation
> for such different water classes. For example ponds usually have less
> complex and less prominent symbolisation because of their size and
> importance. Riverbanks would not need polygon labelling, but rather
> use river (central) line for label placement. Most of GIS/Cartography
> work goes in middle/small scales and it will be impossible to use only
> natural=water there, you would have to add "and water not in
> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
> makes it of the same complexity from coding perspective as original
> water scheme.
>
I agree that it is useful only for primitive rendering of water areas
(that possibly filters water areas by area but does not distinguish
between lakes and rivers). It may be worth mentioning.

But it is also the most typical and common way of rendering things.

>  2. Very important disadvantage of water=reservoir from
> cartographic/gis perspective: it allows mappers to NOT differentiate
> between natural lakes and man made reservoirs. If first point
> describes how different classes are USED, this second point is about
> how these classes are CAPTURED.
>
This is a double edged sword, it also means that mapper unsure
whatever something is natural or man made (common in case
of mapping based on aerial images, sometimes even in
case of survey) is unable to mark a water area.

And distinguishing natural vs man made is still possible 
with water tag anyway.

I was unsure whatever it should be listed as a benefit or
drawback or both sides explained so I ended not 
mentioning this.

(similarly like I have not mentioned that both natural
and landuse are quite counterintuitive key names here)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 14:42 by tomasstrau...@gmail.com:

>> I get that you consider benefits of natural=water water=* schema
>> as unimportant
>>
>
> Can you LIST the benefits? As you see them TODAY. So that we could
> evaluate/compare?
>  (Not point to proposal on wiki, as largest part of it never materialised)
>

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
(just added)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 14:29 by tomasstrau...@gmail.com:

>  And what is a problem of listing benefits of water=reservoir schema?
> If there are none
>
I get that you consider benefits of natural=water water=* schema
as unimportant

But, please, stop pretending that there are no benefits. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging

Dec 16, 2020, 00:17 by zelonew...@gmail.com:

> 1. It is not clear from the original 2011 vote which created water=reservoir 
> (and other values) as to whether the community intended to deprecate 
> landuse=reservoir or whether the community intended to create two parallel 
> tagging schemes for the same object.
>
To be more specific...

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Water_details=633881#Deprecation

""Deprecates" means "is equivalent for all purposes to". For example, landuse 
=reservoir 
 
should be rendered exactly like natural 
=water 
 + water 
=reservoir. There are too many 
uses of the current tagging scheme, and we don't want massive retagging and 
edit wars."

So it was titled as deprecation, redefined deprecation to mean something else 
and
claimed that retagging is not wanted.

Great :(

> Given these issues, I would suggest a narrowly-written proposal that puts 
> forth the clear and specific question as to whether landuse=reservoir should 
> be deprecated.  If that proposal demonstrates clear community consensus for 
> deprecation (per the guidelines in our proposal process), we can update our 
> wiki documentation to explicitly recommend that landuse=reservoir be 
> gradually replaced by natural=water+water=reservoir.  If, instead, that 
> proposal demonstrates that there is still a sizable subset of mappers that 
> prefer the landuse=reservoir tag, we would simply leave both tags documented 
> without caveats, noting the results of both this and the 2011 proposals, and 
> allow the community to sort out which tagging scheme is preferred based on 
> actual usage over time.
>
> As I am the one that raised this issue in the first place, I would be happy 
> to draft such a proposal for consideration.  I want to be clear that in such 
> a proposal, any instances of disrespectful or insulting commentary directed 
> towards any group or individual will not be tolerated and will be immediately 
> brought to the attention of the wiki admins for followup.
>
> Would this be satisfactory to the group in resolving the question of 
> reservoir tagging?
>
Yes, though note that it is likely to just reconfirm stalemate.

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


Re: [Tagging] Changes to clarify the Hazards proposal during the vote

2020-12-15 Thread Mateusz Konieczny via Tagging
+1, this kind of change is completely fine


Dec 15, 2020, 06:19 by graemefi...@gmail.com:

>
> Thanks Brian.
>
> As far as I am concerned, those changes are fine.
>
> Graeme
>
>
> On Tue, 15 Dec 2020 at 10:53, Brian M. Sperlongano <> zelonew...@gmail.com> > 
> wrote:
>
>> Hello,
>>
>> I recently received late feedback on the hazards proposal.  Based on the 
>> feedback, I felt it was necessary to make small changes to this proposal. 
>>

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


Re: [Tagging] How to tag entire group of rentable holiday cottages?

2020-12-15 Thread Mateusz Konieczny via Tagging



Dec 15, 2020, 03:33 by graemefi...@gmail.com:

> On Mon, 14 Dec 2020 at 21:28, Paul Allen <> pla16...@gmail.com> > wrote:
>
>>
>> I can't think of an English term, other than "holiday cottages."  These 
>> places
>> generally call themselves "Foo Holiday Cottages" or "Foo Holidays" or
>> "Foo Farm Cottages" or things like that.
>>
>
> I'm with Paul for Holiday Cottages.
>
> How about tagging the whole area as tourism=chalet + name=Foo Cottages + 
> capacity=25
> then tagging each individual cottage / cabin as either
> building=cabin / bungalow + name=xxx?
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dcabin
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dbungalow
>
>

I am fine with that and I plan to restore this tagging recommendation
unless someone will proposed a better one.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-14 Thread Mateusz Konieczny via Tagging



Dec 14, 2020, 22:03 by and...@torger.se:

> Ok, understood. However as far as I know OSM lacks a standard document 
> for render implementors to actually know how data should be interpreted.
>
In part it is https://wiki.openstreetmap.org/ in part it is decision of
authors of map style how they want map data to be intererpreted.

> The only reason I get here is when the OSM wiki doesn't have answers
>
Yes, you are raising some very interesting cases (for example case of mountain
and peaks named separately).

> Even here there are various answers and ideas circulating
>
This is whole point of tagging mailing list for features with no known
good way of tagging them. (or where it is not documented)

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


Re: [Tagging] How to tag entire group of rentable holiday cottages?

2020-12-14 Thread Mateusz Konieczny via Tagging



Dec 14, 2020, 10:07 by marius...@gmail.com:

> On 14.12.2020 07:19, Mateusz Konieczny via Tagging wrote:
>
>>
>> There are cases where there is group of multiple holiday cottages,
>>
>> each rentable independently. I know about cases with just 2 and big groups, 
>> 25 in one place.
>>
>> How it should be tagged?
>>
>> I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
>> that is for a single one.
>>
>
> There is an old edit error present on this page. The "This could apply to 
> nodes (single chalet) or areas (a group of chalets)." is incorrectly placed 
> in "Tags used in combination" instead of "How to map" chapter.
>
> See the old version, just before "Tags used in combination"" was added - > 
> https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=1296833
>
I fixed this edit.

I spotted two more:
https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=prev=1448037
https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=prev=1249899

that discouraged using this tag for group of them.

So my questions are: what is the UK (or English in general) word for location 
with group
of holiday cottages? Especially group of them in a fenced area, with shared 
amenities 
such as restaurant/cafeteria, firepit, maybe sauna or lake access.

But without extensive entertainment infrastructure that would qualify for 
leisure=resort.

Would it be a good idea to revert this two edits and fully restore 
recommendation
to use tourism=chalet for group of chalets?

Or maybe we need a new tag?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-14 Thread Mateusz Konieczny via Tagging
Relations are quite obnoxious in regular editing and also
during actually using the data.


Dec 14, 2020, 08:07 by and...@torger.se:

>
> Why is the relation problematic (honest question)?
>
>
> I was starting to think that some sort of naming relation could be the 
> answer, ie you put both peaks in a relation with for example type=name; 
> natural=mountain; name=Kebnekaise.
>
>
> In addition one should write clearly that peak serves dual purpose both as 
> naming peaks and mountains. Today on the wiki the peak is clearly defined as 
> only the summit, but it's often used as naming mountains where the peak is 
> nameless.
>
>
> What we also could have is fuzzy naming areas, which we would need in some 
> way or another at some point anyway, so you would have an area covering the 
> mountain with name=Kebnekaise. I would have no problem with that, but it 
> seems to that it must be in a separate database as it just too controversial 
> to be in the main database.
>
>
> /Anders
>
>
> On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:
>
>
>>  
>>  
>>  
>> Dec 13, 2020, 19:58 by and...@torger.se:
>>
>>>
>>> Do you have a suggestion of how to map Sweden's highest mountain, 
>>> Kebnekaise?
>>>
>>>
>>> The mountain is called Kebnekaise, it has two peaks, one is called 
>>> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>>>
>>>
>> I admit that I have no good idea, if I would run into such case and failed 
>> to find a better idea
>> (hopefully one will come) I would invent a new way to tag that.
>>  
>> natural=mountain? Main problem is where to put it - node at arbitrary 
>> position between peaks?
>> Node at location of highest peak? Area? Relation? All of that is sadly 
>> problematic.
>>
>>>
>>> (The mountain_range tag is a great tag, but I note that its status is just 
>>> "in use", it's not an approved tag :-O.)
>>>
>>>
>> It is perfectly fine to use tags that never went through tagging proposal, 
>> though
>> I am not going to endorse this one. Tagging mountain ranges seems to poorly 
>> fit OSM
>> with multiple different opinions where mountain range starts/ends and 
>> inability to
>> verify it by survey.
>>  
>> All tags were in some stage rarely used before becoming heavily used,
>> only some cases went through a proposal process.
>>
>> ___
>> 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] How to tag entire group of rentable holiday cottages?

2020-12-13 Thread Mateusz Konieczny via Tagging

There are cases where there is group of multiple holiday cottages,

each rentable independently. I know about cases with just 2 and big groups, 25 
in one place.

How it should be tagged?

I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
that is for a single one.

Tagging 25 tourism=chalet independently is sill when they form
single object, not 25 separate ones.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-13 Thread Mateusz Konieczny via Tagging



Dec 13, 2020, 19:58 by and...@torger.se:

>
> Do you have a suggestion of how to map Sweden's highest mountain, Kebnekaise?
>
>
> The mountain is called Kebnekaise, it has two peaks, one is called 
> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>
>
I admit that I have no good idea, if I would run into such case and failed to 
find a better idea
(hopefully one will come) I would invent a new way to tag that.

natural=mountain? Main problem is where to put it - node at arbitrary position 
between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly 
problematic.

>
> (The mountain_range tag is a great tag, but I note that its status is just 
> "in use", it's not an approved tag :-O.)
>
>
It is perfectly fine to use tags that never went through tagging proposal, 
though
I am not going to endorse this one. Tagging mountain ranges seems to poorly fit 
OSM
with multiple different opinions where mountain range starts/ends and inability 
to
verify it by survey.

All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-13 Thread Mateusz Konieczny via Tagging
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Examples

Looking at the first example - I see nothing clearly indicating that pump is 
operated
by muscle power.

Is it intentional to not include this distinction?


Dec 13, 2020, 19:45 by fl.infosrese...@gmail.com:

> Dear all,
>
> Following some rework to take care of comments received during the first 
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section clearer.
> Classification of pumps is now done with pump_mechanism and is still 
> equivalent to which available on Wikipedia. Numerous references are made 
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as 
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote 
> could begin by next Saturday.
>
> Best regards
>
> François
>

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Mateusz Konieczny via Tagging



Dec 13, 2020, 19:53 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 13. Dec 2020, at 18:49, Tomas Straupis  wrote:
>>
>>  Introducing duplicate and unused schema (especially as the only
>> option) is not a good IT decision, basic analysis should have shown
>> that. But in case of id it was technology leading functionality and
>> thus leading users when in IT it must be the other way round -
>> usage/requirements must lead technical decisions. That is IT BASICS.
>> Lack of such understanding is the reason why I claim iD developers
>> lacked basic IT knowledge
>>
>
>
> it is indeed well documented that there was a period in iD development where 
> the developers occasionally  (initially without actively communicating it and 
> later openly and deliberately) dismissed the existing tagging wiki docs and 
> mailing list and tag stats, but I think it should be mentioned that it was 
> the former developer. Brian, maybe this was before you started to follow the 
> lists. You can browse through older closed iD tickets to see some discussion, 
> there’s also a wiki page about the topic: > 
> https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
>
Yes, it happened. I considered some decisions as problematic.

But it was not about IT basic, IT knowledge, IT decisions or anything like that.

If someone complains about IT knowledge while the actual complaint
is about tagging presets then people will be very confused.

BTW, iD presets were recently extracted into 
https://github.com/openstreetmap/id-tagging-schema
to 100% decouple preset decisions that are not 
programming related for programming tasks of making editor.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - crossing=priority

2020-12-13 Thread Mateusz Konieczny via Tagging
It seems to be proposing also belisha_beacon=yes that
is now unused
https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes

At the same time it has 
"However, in countries like the UK, where belisha beacons are used, every 
single zebra crossing has belisha beacons installed, so there is no need to tag 
them"

There is also
"Indicates the presence of a "belisha beacon" at the crossing. (Most likely 
unnecessary, discuss below)"

Given there is no indication that it would be useful or needed I think
that it should be not proposed.

If that it would be useful or needed it can be proposed separately.

Note that having two proposals in one will result in people voting against
if there are against any of them, so splitting would be a good idea
anyway.

Dec 13, 2020, 20:25 by tagging@openstreetmap.org:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
>
> Thanks,
> IpswichMapper
>

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Mateusz Konieczny via Tagging



Dec 13, 2020, 19:33 by tomasstrau...@gmail.com:

> 2020-12-13, sk, 20:09 Mateusz Konieczny via Tagging rašė:
>
>> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
>> Mateusz, can you point out which of my claims is a lie?
>>
>> "iD coders decided to skip standard IT processes of product development
>> (or were not familiar with the basics of IT)"
>>
>
> Let's go back in time. It is 2012. iD developers are to add water
> tagging schema to their newly baked editor. The candidates are IN
> 2012:
>  1. landuse=reservoir - the only schema in activu use, widely used,
> 200K objects tagged, documentation written, tutorials written.
>  2. water=reservoir - unused (5K? 10K?).
>  iD developers decision: go with option 2. I do not see how such
> decision could be counted as "IT-wise sound"?
>
Following outcome of approved proposal that you dislike
is not indicator of not following
standard IT processes of product development.

Again, disagreeing with you does not mean that someone is
incompetent.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Mateusz Konieczny via Tagging



Dec 13, 2020, 18:46 by tomasstrau...@gmail.com:

Please first stop quoting me in way that presents your
statements under my autorship

> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> Mateusz, can you point out which of my claims is a lie?
>
"iD coders decided to skip standard IT processes of product development
 (or were not familiar with the basics of IT)"


"coders of iD decided to lie to the users that landuse=reservoir is
deprecated which it never was"

It is deprecated by 2011 proposal, 
seehttps://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation




>  I didn't say iD invented duplicate schema, I said that schema was
> lying dead until iD decided to introduce it as the only way to tag
> water, introduction "launched" new water schema adding any
> considerable usage (as it was the only option for iD mappers).
>
OK, this one was based on miscommunication.



>  Introducing duplicate and unused schema (especially as the only
> option) is not a good IT decision
>
It was not an unused schema.

> usage/requirements must lead technical decisions. That is IT BASICS.
>
It was not an unused schema and it was proposed, approved and used before iD
started using it and later aggressively promoting it.

>  and introduced
>
>> water=reservoir as the only way to tag, all this at the time when
>> water=reservoir usage was close to zero!
>>
>> See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology
>>
>> Usage in January 2019 was about 200 000 already.
>>
>> "water=reservoir usage was close to zero" is untrue
>>
>
> Key word "introduced" so it is 2012, not 2019.
>  water=reservoir usage in 2012 is close to zero.
>
Then iD followed a fresh approved proposal, so relatively low
usage is not surprising.

Though it is a rare case when I encounter complaint about iD
developers following outcome of a proposal process.

>> It is deprecated by 2011 proposal, see
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation
>>
>
> The author of this proposal agreed that standard water schema is NOT
> deprecated. 
>
It is not changing that this vote deprecated landuse=reservoir.
Maybe it is a bad decision that should be ignored, but
it is not changing that deprecation happened.

> And a few people voting in wiki cannot deprecate a tag.
>
That is one of methods to deprecate tag, even if you dislike it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Mateusz Konieczny via Tagging


Dec 13, 2020, 16:35 by tomasstrau...@gmail.com:

> 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
>
>> 2019 was a turning point, and over the last two years, landuse=reservoir has
>> been on a steady decline, while water=reservoir continued its rapid growth.
>>
>
> New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better
>
This is 100% untrue, and you insult people. Stop making such things.

For start, iD authors (also ones that made decisions about tagging
presets that I consider to be mistakes and going against consensus)
had no problem with basics of IT and IT processes of product development.

water=reservoir was launched (created) in 2011
see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID )

> , and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology

Usage in January 2019 was about 200 000 already.

"water=reservoir usage was close to zero" is untrue
 

>  And the only reason for change of stat starting 2019 is because
> coders of iD decided to lie to the users that landuse=reservoir is
> deprecated
>
It is deprecated by 2011 proposal, see
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation


>  So the change of statistics is not the preference of mappers but
> preference of some nerds.
>
Well, tagging mailing list and community that is engaged in voting
on tagging proposals is not very representative.

But if you care about deprecation decisions you must rely on
people that are engaged in such discussions.

> I would propose to deprecate water=reservoir
>
Feel free to make a proposal that would
revert
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details 

proposal. 


BTW, you are AGAIN spreading false statements and claim that iD
invented water=reservoir. Please stop doing this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Mateusz Konieczny via Tagging
on topic of landuse=reservoir vs water=reservoir

I have strong preference toward version with natural=water,
but landuse=reservoir is clearly still in significant use

on topic of what is deciding for tag popularity


Dec 13, 2020, 15:31 by pla16...@gmail.com:

> On Sun, 13 Dec 2020 at 14:13, Brian M. Sperlongano <> zelonew...@gmail.com> > 
> wrote:
>
>>
>> Is it time to more directly recommend that mappers favor natural=water + 
>> water=reservoir *instead of* rather than *in addition to* landuse=reservoir?
>>
> The reality is that no matter what it says in the wiki and no matter what
> conclusions we reach on this list, tagging practise is largely determined
> by editor presets.
>
This statement ignores that editor presets are strongly influenced by this
things.

Yes, there were some cases where iD developers
completely or mostly ignored existing documentation 
(at least one ongoing), but this cases were rare and explosive.

> (a very small fraction of users tag
> manually, but most do not).
>
This "very small fraction" is much more active than other
mappers and they have very significant influence on tagging.

Tagging discussions (here and elsewhere), wiki docs,
mappers tagging tags directly have a very big influence
especially for establishing new tags.

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


Re: [Tagging] Mapping bicycle-only turn lanes

2020-12-13 Thread Mateusz Konieczny via Tagging



Dec 12, 2020, 14:25 by ba...@ursamundi.org:

>
>
> On Sat, Dec 12, 2020 at 5:25 AM Jan Michel <> j...@mueschelsoft.de> > wrote:
>
>> Hi,
>>  where do you see a problem here? The current situation might not be 
>>  perfect, but it is usable as it is. The only thing to keep in mind is 
>>  that the number of "lanes" does not need to match the number of entries 
>>  in the "XY:lanes" tags.
>>
>
> That disagrees with literally every lane editing and validation tool in 
> existence at this time.
>
Can you give examples of validation tools and lane editing software that 
disagrees
with it?

The proper solution would be to make tag traffic_lanes or something that
would count also bicycle lanes, not redefine lane tag.

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


Re: [Tagging] Feature Proposal - RFC - wait

2020-12-13 Thread Mateusz Konieczny via Tagging
Seems well done to me.

I even know two places where it would be taggable.


Dec 13, 2020, 06:28 by antoniomade...@gmx.com:

> Greetings.
>
> As discussed here in the mailing list, me and L___I have created a
> proposal for the key "wait":
> https://wiki.openstreetmap.org/wiki/Proposed_features/wait
>
> Please, comment here in the list or in the wiki talk page.
>
>
> Previous discussions:
> https://lists.openstreetmap.org/pipermail/tagging/2020-May/052321.html
> https://forum.openstreetmap.org/viewtopic.php?id=69011
>
>
> Regards,
> António.
>
> ___
> 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] Mapping bicycle-only turn lanes

2020-12-12 Thread Mateusz Konieczny via Tagging



Dec 12, 2020, 18:27 by ba...@ursamundi.org:

>
>
> On Sat, Dec 12, 2020 at 11:22 AM Jan Michel <> j...@mueschelsoft.de> > wrote:
>
>> On 12.12.20 17:47, Paul Johnson wrote:
>>  > On Sat, Dec 12, 2020 at 10:46 AM Jan Michel 
>>  > <>> j...@mueschelsoft.de>>  
>>  > > j...@mueschelsoft.de>> >> wrote:
>>  > 
>>  >     On 12.12.20 17:25, Paul Johnson wrote:
>>  > 
>>  >      > Sure, if you manually torque tag it to match the incorrect
>>  >      > documentation.  As soon as you open the lane editor, it rightly
>>  >     corrects
>>  >      > it to lanes=5, since you have 2 lanes in one way and 3 in the 
>> other.
>>  > 
>>  >     The "incorrect documentation" was voted on and it was approved.
>>  > 
>>  > 
>>  > I'm pretty sure it was done without consideration for reserved lanes as 
>>  > lane access tagging wasn't something yet available.  Now it is, and it's 
>>  > time to reconsider that.
>>  
>>  I'm refering to the proposal of exactly this: the :lanes extension. It 
>>  was clearly and unambiguously taken into account:
>>  >> 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag
>>
>
> That specific anchor says it's completely sidestepping the issue while 
> highlighting the shortcoming of lanes=* as it stands now.  We need to fix 
> lanes=* to mean all lanes.  This isn't a hard change to make
>
It would redefine widely used tag.

So we would need to resurcey all places where lanes tag is used.

And MapRoulette is not an answer in this case. It would only work if all 
11 millions tags would be in places where aerials is highly detailed, 
up to date and road is not covered by trees.

See https://taginfo.openstreetmap.org/keys/lanes

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


Re: [Tagging] edit war related to tagging of a bus-only major road

2020-12-11 Thread Mateusz Konieczny via Tagging
It is very unusual, but I think that highway=secondary may be actually bus only.

 And I would never describe highway=secondary as a special type of 
highway=service

Dec 11, 2020, 14:21 by jan...@gmail.com:

> I think "service" is more appropriate than highway=secondary. Highway=service 
> has in my opinion a wider scope than secondary. In a way, secondary is a 
> special type of highway=service (that's the way I look at it, though other 
> mappers probably don't look at it that way). So if a road can not be 
> classified in other ways, use highway=service. If you have a better, more 
> narrow scope tag, like highway=busway, use that. 
>
> Janko
>

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


[Tagging] Mapping bicycle-only turn lanes

2020-12-08 Thread Mateusz Konieczny via Tagging
Mapper in Poland run into a tricky case and asked for help.

I am forwarding this a bit weird case.

Photo is at 
https://commons.wikimedia.org/wiki/File:Krak%C3%B3w_Brodzi%C5%84skiego_(5).jpg
and depicts 

- contraflow bicycle lane
- bicycle-only left turn lane (signed left turn)
- general purpose lane (unsigned turn)

How this should be tagged?

Following is my idea but...

highway, name, lit=yes, surface=asphalt etc
oneway=yes
oneway:biycle=no
lanes=1 (as bicycle lanes are not counted)
vehicle:lanes:forward=no|yes
bicycle:lanes:forward=designated|yesturn:bicycle:lanes:forward=left|
turn:lanes:forward=|
vehicle:lanes:backward=no
bicycle:lanes:backward=designated
cycleway:left=lane
cycleway:right= - there is left turn lane only, so cycleway:right=lane 
would be
not entirely correct but there is a left turn lane, cycleway:right would be 
worse
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Many historic=wayside_cross are not historic

2020-12-08 Thread Mateusz Konieczny via Tagging
See https://wiki.openstreetmap.org/wiki/Counterintuitive_key_names
for other similar cases.

historic=wayside_shrine, historic=wayside_cross were intended for tagging old 
shrines
and old crosses. But introducing them was done without proposing a tagging 
scheme
for modern crosses and modern shrines. As result tags changed meaning and are 
used
for any shrine and any cross, including those that are neither historic nor 
wayside.

For crosses there is also man_made=cross but with lower usage and support.

For shrines noone proposed new tag for shrines that are not qualifying
for amenity=place_of_worship and are modern rather than historic.

Dec 7, 2020, 23:30 by vosc...@gmail.com:

> I am sure someone has made this observation before me:
> Many historic=wayside_cross and historic=wayside_shrine are not historic 
> objects in the sense of the definition of the > wiki page Historic 
> >  which reads:
> "The > historic > =*>  key 
> is used to identify features that are of historic interest"
> We have 130k "historic" wayside crosses and 80k "historic" wayside shrines in 
> the database.
> Many of these are "mine" and many of these are certainly not of any 
> historical interest, they are often not even old. But some few certainly are 
> historic.
>
> Volker
> mostly mapping in Italy
>
>

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


Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

2020-12-06 Thread Mateusz Konieczny via Tagging
Thanks for creating a proposal that would solve problems with the current 
tagging!

I like it - and military force that also is tasked with search & rescue can
be also tagged with combination of this two new tags.

Disclaimer: I know nearly nothing about this topic.

But maybe emergency=marine_rescue (or amenity=marine_recsue) would be better
than a brand new key rescue in rescue=marine_rescue tag?

Dec 6, 2020, 03:21 by graemefi...@gmail.com:

> Following on from > 
> https://lists.openstreetmap.org/pipermail/tagging/2020-November/056482.html> 
> , I've also put together a proposal to make some changes to the existing 
> Coast Guard pages.
>
> Please visit > https://wiki.openstreetmap.org/wiki/Marine_rescue>  & have a 
> look.
>
> All comments welcome either here or on the Talk page.
>
> (& as I just said, these are my first actual proposals, so please be gentle!)
>
> Thanks
>
> Graeme
>

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


Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

2020-12-03 Thread Mateusz Konieczny via Tagging



Dec 3, 2020, 19:14 by p...@trigpoint.me.uk:

> On Thu, 2020-12-03 at 18:06 +, Paul Allen wrote:
>
>> On Thu, 3 Dec 2020 at 17:54, Mateusz Konieczny via Tagging <>> 
>> tagging@openstreetmap.org>> > wrote:
>>
>>>
>>> I am not exactly happy about "rock slide" as it seems weird to use it where
>>> danger is primarily about individual rocks dropping, not about full scale 
>>> rock slide.
>>>
>>
>> In the UK we do not appear to have any signage warning of landslides.  The
>> one sign we have is described as warning of "falling or fallen rocks."  A
>> landslide is very different to falling rocks.
>>
>> That's not to say we don't have landslides in the UK, but it appears
>> we don't construct roads in places where they are anticipated to
>> happen.
>>
>
> https://en.wikipedia.org/wiki/A625_road#Mam_Tor_road
>
>

See ongoing "Rest and Be Thankful" mountain pass landslide.

https://www.openstreetmap.org/changeset/95243064
https://www.openstreetmap.org/note/2450961
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

2020-12-03 Thread Mateusz Konieczny via Tagging
I am not exactly happy about "rock slide" as it seems weird to use it where
danger is primarily about individual rocks dropping, not about full scale rock 
slide.

Personally I would prefer "failing rocks" for warning used by a standard road
sign.

(difference is minor, but if we have luxury of selecting any value...)

Disclaimer: I am from a relatively flat country, maybe this sign warns about
full scale rock slides elsewhere?



As far as I know such dangers are common in Asia, especially mountainous parts
such as Nepal. I wonder how this is signed (and is signed at all).

See for example second image on 
https://blogs.agu.org/landslideblog/2020/10/26/landslides-and-roads-recent-examples/
or https://blogs.agu.org/landslideblog/2020/10/20/hanyuan-county-1/
or other materials from that blog.


Dec 3, 2020, 18:14 by zelonew...@gmail.com:

> Hello,
>
> I've made a number of updates to the "hazard" proposal [1] based on the input 
> received.  Thanks to those that offered comment and feedback so far during 
> this RFC.
>
> I request community help on resolving feedback on the proposed tag 
> hazard=rock_slide and deprecation of three values of hazard: rockfall, 
> falling_rocks, and landslide.  The feedback was that rock falls, rockslides 
> and landslides are different and should not be conflated in a single value.  
> Indeed, geologically they are different; a "fall" implies material falling 
> from a cliff while a "slide" implies material sliding down a slope.  
> Additionally "rock" versus "land" describes a different type of material that 
> might fall or slide.
>
> However, in standard road signage, there is a single pictogram for all of 
> these forms of falling/sliding material that almost universally depicts a 
> steep slope with pieces of falling debris.  See the referenced wikipedia 
> articles [2][3] in the row labelled "falling rocks or debris" for examples in 
> many countries.
>
> In some cases, this pictogram is also combined with text that further 
> specificies "landslide" [4] or signs might say in words only "rock slide 
> area" or "slide area".  The "falling rocks or debris" sign is also commonly 
> used by itself to generally indicate this category of hazard.  In these cases 
> (the falling rocks/debris pictogram sign used by itself), my thinking was 
> that a mapper should have a single tag that they can apply, without having to 
> specifically determine the exact geological character of the rock/land 
> fall/slide hazard.  Thus, I've proposed to adopt the most common variant 
> "rock_slide" to cover all of these cases, which a mapper could use anytime 
> they map a sign with that pictogram, and deprecate the others, in order to 
> create consistent tagging.
>
> I request community feedback on this specific question of how to tag this 
> type of hazard for cases of:
> (a) When the mapper observes the "falling rocks or debris" sign but is unsure 
> of whether it is specifically a rock/land slide/fall
> (b) When the mapper observes the sign, and knows the specific geological type
> (c) When the mapper observes a sign with specific text that states "falling 
> rocks", "rock fall", or "landslide"
>
> Do these distinctions need to be tagged differently, and if so, are there 
> suggestions on how that tagging might be constructed?
>
> [1] > https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
> [2] > 
> https://en.wikipedia.org/wiki/Comparison_of_MUTCD-influenced_traffic_signs
> [3] > https://en.wikipedia.org/wiki/Comparison_of_European_road_signs
> [4] > 
> https://www.pdsigns.ie/product/safety-construction-hazard-warning-risk-of-landslide-on-cliff-edge-sign/>
>   (note: commercial site)
>

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


Re: [Tagging] Inclined elevators

2020-12-03 Thread Mateusz Konieczny via Tagging
Is it both something that makes sense, accepted by community 
and supported by Wiki?

In such case, have you checked whatever this feature was already requested
for mentioned software?

It is both rare(?) and tricky to implement in rendering, but editors have 
greater freedom to handle
this.

And it may be possible to support it at least partially, for example for 
routing (in OsmAnd).


Dec 3, 2020, 14:17 by guilla...@chauvat.eu:

> Hi,
>
> My apologies if this has already been discussed several times or if it's not 
> the place to ask.
>
> I was mapping a public inclined elevator in a dedicated building (it only 
> contains the elevator and three parallel escalators). This is really a 
> standard elevator running parallel to the escalators, not a funicular. Those 
> elevators are very common here in Sweden, although most often inside metro 
> stations.
>
> What is the best way of mapping it? I used a way tagged with highway=elevator 
> as the wiki recommends, but this does not seem supported by any tool (the 
> default editor, the map on openstreetmap.org, or osmand).
>
> Regards,
> Guillaume
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

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


Re: [Tagging] Inclined elevators

2020-12-03 Thread Mateusz Konieczny via Tagging
This one looks to me like a small funicular railway.

But OSM Wiki includes "the ascending and descending vehicles counterbalancing 
each other"
as one of important characteristic.

https://wiki.openstreetmap.org/wiki/Tag:railway=funicular?uselang=en


Dec 3, 2020, 14:53 by winfi...@gmail.com:

> I couldn't resist looking them up.
>
> This is a very long one and there is even an operator in it: > 
> https://www.youtube.com/watch?v=Wh0NxK6sslM
>
> Most are the length of the escalators they are adjacent to.
>
> Polyglot
>
> On Thu, Dec 3, 2020 at 2:19 PM Guillaume Chauvat <> guilla...@chauvat.eu> > 
> wrote:
>
>> Hi,
>>
>> My apologies if this has already been discussed several times or if it's not 
>> the place to ask.
>>
>> I was mapping a public inclined elevator in a dedicated building (it only 
>> contains the elevator and three parallel escalators). This is really a 
>> standard elevator running parallel to the escalators, not a funicular. Those 
>> elevators are very common here in Sweden, although most often inside metro 
>> stations.
>>
>> What is the best way of mapping it? I used a way tagged with 
>> highway=elevator as the wiki recommends, but this does not seem supported by 
>> any tool (the default editor, the map on >> openstreetmap.org 
>> >> , or osmand).
>>
>> Regards,
>> Guillaume
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my 
>> brevity.___
>>  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] Animal trails

2020-12-01 Thread Mateusz Konieczny via Tagging



Dec 1, 2020, 00:44 by dieterdre...@gmail.com:

>
>
> Am Di., 1. Dez. 2020 um 00:39 Uhr schrieb Lukas Richert <> 
> lrich...@posteo.net> >:
>
>>
>> I wouldn't tag this as foot=no or access=no. There are many  trails in 
>> my area that are clearly animal tracks and seldom used  by people - but 
>> it is allowed for people to walk on these and they  are sometimes 
>> significant shortcuts so allowing routing over them  in some cases would 
>> be good. 
>>
>>
>
> +1
>
+1, though in cases of protected areas with "do not leave signed trails" rules, 
access=no
would be a viable tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Animal trails

2020-12-01 Thread Mateusz Konieczny via Tagging
Given "in the field they may also look like trails." it seems to not be 
solvable.

How mappers are supposed to distinguish them from normal paths?

Nov 30, 2020, 20:41 by s8e...@runbox.com:

> 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] How to tag for dualband GPS ?

2020-11-30 Thread Mateusz Konieczny via Tagging


Nov 30, 2020, 14:33 by amadva...@gmail.com:

> On Mon, Nov 30, 2020 at 12:27 PM Warin <> 61sundow...@gmail.com> > wrote:
>
>> imagery may well be  better than survey by consumer GPS
>>
> I agree. Where an image is available I always use it as reference. But most 
> of the trails of my local area are under the woods (low mountain) and the GPS 
> is the only source of information.
>
Check whatever LIDAR is available! My region has high-quality LIDAR data on
a compatible license allowing to - for example - map paths in a forest
based on elevation data.


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


[Tagging] Defining amenity=coast_guard

2020-11-30 Thread Mateusz Konieczny via Tagging
I run into https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcoast_guard
and despite that I have basically zero experience with such objects 
I am pretty sure that this description (and an old proposal) has a
problematic definition

It was "A building housing the Coast Guard administrative offices"
what seems clearly bad:

- we have building tags for buildings
- this clearly tags coast guard facility (office? station?), not
  building housing it
- this matters for cases like https://www.openstreetmap.org/relation/1573145
  with more than one building
- what about Coast Guard parts that are not administrative?

Change description to refer to "coast guard base"?
Describe office=government as better for
"Coast Guard administrative offices" and mark it as replaced?
Recommend landuse=military / amenity=police if applicable in
a given country?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag for dualband GPS ?

2020-11-30 Thread Mateusz Konieczny via Tagging
I would use "survey using high quality dualband GPS (accuracy with X m)"
to make it clearly understandable.

Most people would be unaware of meaning of "GPS dualband"
(I ma quite interested in this topic and I am unsure what is the accuracy
difference, especially as there massive differences in
accuracy between smartphone GPS receivers and more dedicated 
GPS receivers - even Garmin etrex will have much higher accuracy)



Nov 29, 2020, 22:45 by amadva...@gmail.com:

>
> Hi,
>
> I bought a tracking device that supports GPS dualband (also called dual 
> frequency) for high precision mapping, and I'm wondering if I can put this 
> information in the "source" tag.
>
> The intention is to make future mappers consider the device precision when 
> doing corrections.
>
> Here some info about this new kind of GPS: > 
> https://www.gps-forums.com/threads/what-is-dual-band-gnss.46938/
>
>
>
> At present I'm thinking to use "source=survey;GPS;dualband"
>
> What do you think?
>
>
> Ciao,
> Andrea
>
>

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


Re: [Tagging] Feature Proposal - RFC - Hazards

2020-11-25 Thread Mateusz Konieczny via Tagging
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)

Currently it is implied that it is not taggable, it would be good to have it 
mentioned explicitly.

Why hazard:animal and hazard:species is needed instead of animal and species? 

--

The use of hazard =rock_slide 

 is more popular than several alternatives, 
which are essentially describing the same thing: a hazard where rocks, earth, 
or mud might fall from above.

There is a big difference between rock slide, failing rocks and landslide.

I do not thing that deprecation of failing_rocks and landslide is a good idea,
I would keep them (I have seen signposted sign about landslide exactly once,
many, many signs of failing rocks - tagging rock_slide for either of them would 
be incorrect).

Nov 25, 2020, 14:12 by zelonew...@gmail.com:

> Comment is requested on the proposal "hazard", which describes hazardous or 
> dangerous features.  This tagging was first proposed in 2007, and I have 
> adopted the proposal with permission from the original author.  Thanks to the 
> various folks that assisted in the development of this proposal prior to this 
> RFC.
>
> The key "hazard" has achieved over 28,000 usages, and it is proposed to 
> formalize usage of the most popular values of this key while deprecating 
> less-popular synonyms.  In addition, this proposes to deprecate 
> protect_class=16 in favor of the hazard key.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>

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


Re: [Tagging] Elevated housing estate

2020-11-24 Thread Mateusz Konieczny via Tagging
add location=overhead on buildings and other objects?
https://wiki.openstreetmap.org/wiki/Key:location

https://wiki.openstreetmap.org/wiki/Key:building:min_level 
https://wiki.openstreetmap.org/wiki/Key:building:levels#Buildings_with_parts_that_don.27t_start_at_ground_level
(not sure can it be applied if entire building starts above ground level)

Certainly add also description=* tag with info what is happening here,
maybe with link to this mailing list thread.


Nov 25, 2020, 01:00 by graemefi...@gmail.com:

> How do you tag an area, in this case an entire housing estate!, that is 
> raised up above ground level?
>
> https://www.google.com.au/maps/@-28.065772,153.3799853,3a,15y,117.51h,89.21t/data=!3m6!1e1!3m4!1sN_TJvFHJyLff1E4GmiCSjQ!2e0!7i13312!8i6656?hl=en
> (with the usual not mapping from Google ...)
>
> Just draw the outline of the area & tag it as level=1?
>
> The main entry is via a bridge: > 
> https://www.google.com.au/maps/@-28.0673717,153.3800556,3a,23.4y,28.84h,87.1t/data=!3m6!1e1!3m4!1sBF_8z5ekricuuEFZnUJioQ!2e0!7i13312!8i6656?hl=en>
>  ,
> which is ok, but should all the internal roads also be marked as bridges?
>
> Thanks
>
> Graeme
>

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-24 Thread Mateusz Konieczny via Tagging



Nov 24, 2020, 15:09 by walker.t.brad...@gmail.com:

>
> I’ve seen the micro grants, I’m not talking about funding from OSM 
> Foundation.  Basically if someone could identify a solution to some of the 
> problems that come up in this tagging thread like “updating how X rendering 
> process works”, and the community agrees, an appropriate developer(s) could 
> be hired to fix that, which would enable other things.
>
>
I know, I linked it because it was closest thing to what was described and it 
gives some perspective
about likely funding needed.

> For example more complete and systematic local languages translation, 
> “better” cartographic representation (two weeks ago conversation), more 
> complicated water tags (a frequent topic here), whatever.  
>
Note that the best project would be something that does not require changes to 
mapped 
data to avoid various conflicts.

Not sure what you mean by "more complicated water tags" but it sounds like a 
poor fit,
if by "more complete and systematic local languages translation" you mean
"setting up rendering server that shows name:en/name:pl/named:de/name:whatever 
tags,
not just name tag" then it sounds like a something that has decent chances to 
succed.

> The only “back-end cleanup” proposal I see is the > denied osm2pgsql 
> development 
> >
>  .
>
Note that it was funded by OSMF shortly after:
https://lists.openstreetmap.org/pipermail/talk/2020-August/085174.html


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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-24 Thread Mateusz Konieczny via Tagging
https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020 would kind of 
illustrate
what kind of money was requested for OSM-related projects.

Some of that was pure or nearly pure software development, though most of them
are either funded or were a quite poor proposals.

Nov 24, 2020, 12:19 by walker.t.brad...@gmail.com:

> >Why is nothing in that direction in OSM-Carto right now?  Because no one so 
> >far has invested the volunteer time to do so an no one has invested the 
> >money to pay someone qualified to do so either.  And a large number of 
> >people consider the status quo as good enough.  "The good enough is an enemy 
> >of the great" is a very common pattern in map style development.
>
> Is there a wiki page with a "wish-list" of things, with approximate costs 
> where developers could post?  There is likely a disconnect between those 
> willing to pay, and those who could actually scrounge up the money.  Thus, 
> once consensus on what changes are needed has been achieved, we can scrounge 
> for money?
>
> Walker KB
>
> -Original Message-
> From: Christoph Hormann  
> Sent: Tuesday, 24 November, 2020 11:11
> To: Tag discussion, strategy and related tools 
> Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. 
> water
>
>
>
>> Dave F via Tagging  hat am 24.11.2020 01:24 
>> geschrieben:
>>
>> Yes, but the demand was still made &
>>
>
> So what?  Someone (an individual, not 'OSM-Carto' as a whole) made a 
> suggestion (and not a demand) that turned out to not be such a good idea and 
> therefore did not achieve consensus.
>
>> the solution of writing competent
>> code to enable the proposal was never implemented, so your point is?
>>
>
> I am not sure what you mean here.  One of the problem of tagging boundaries 
> on ways and one of the main reason why the idea did not reach consensus is 
> that it does not solve any of the rendering problems w.r.t. boundaries in 
> substance.
>
> Code for processing OSM boundary data for cartographic applications exists.  
> Not all of it is open source and much of it is just rough implementations not 
> robust enough for routine use.  And there are of course very different 
> cartographic problems to solve w.r.t. boundary rendering.  Why is nothing in 
> that direction in OSM-Carto right now?  Because no one so far has invested 
> the volunteer time to do so an no one has invested the money to pay someone 
> qualified to do so either.  And a large number of people consider the status 
> quo as good enough.  "The good enough is an enemy of the great" is a very 
> common pattern in map style development.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-24 Thread Mateusz Konieczny via Tagging



Nov 24, 2020, 01:24 by tagging@openstreetmap.org:

>
>
> On 22/11/2020 22:27, Christoph Hormann wrote:
>
>> Exactly. It also shows how we in OSM traditionally make decisions about 
>> tagging. An idea to change tagging practice was suggested - on an open 
>> channel for everyone to read and comment on without hurdles and with an 
>> archive that allows us now to read up on things years later. It was 
>> discussed and arguments and reasoning were provided both for and against the 
>> idea and based on that we reached consensus that it was a bad idea and it 
>> was abandoned.
>>
>
> Yes, but the demand was still made & the solution of writing competent code 
> to enable the proposal was never implemented, so your point is?
>
You claim was that:
- this code is trivially easy to implement
- that developers failed to do so "purely because they can't be bothered/not 
competent enough"
- and presented as something happening right now, without mention that it 
refers to something
suggested/proposed/demanded year ago and abandoned also years ago

And you topped it with 
"if developers are offended at receiving suggestions on how to improve their 
software, or even have it criticized, then they should rescind it."

Yes, I am offended. But it was not a suggestion. It was a baseless insult and 
misrepresentation of
a situation, that is generally not useful or desirable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Mateusz Konieczny via Tagging



Nov 22, 2020, 19:00 by tagging@openstreetmap.org:

> I'm surprised you think that as you were a contributor to the discussions:
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/3102
>
This is a closed, not implemented PR. So it is not a case of
"OSM-carto demanding boundaries on ways".



> https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html
>
Yes, long time ago there was a problematic idea that was abandoned.

Describing something like that over two years later as 
"OSM-carto demanding boundaries on ways" - in present tense and 
with claim that it is technical issue caused by incompetent programmers
is misleading at best.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Mateusz Konieczny via Tagging



Nov 22, 2020, 19:34 by tagging@openstreetmap.org:

>
>
> On 22/11/2020 18:12, Clay Smalley  wrote:
>
>> On Sun, Nov 22, 2020 at 11:12 AM Dave F via  Tagging <>> 
>> tagging@openstreetmap.org>> >  wrote:
>>
>>>
>>>
>>> Contributing to the database (also *volunteers*) are  expected 
>>> to map to a certain standard. There shouldn't be  a reason to 
>>> expect develops not to do the same.
>>>
>>
>> If it's so easy, why don't you write the "few lines ofcode" 
>> necessary to fix this issue?
>>
> I did. Note the response.
>  > 
> https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-372455636
>
The mention was about "few lines ofcode" necessary to fix this issue

Not about lines of code making something similar on a different software stack,
that is not fixing the issue at all.

And the very next comment is

> Exactly, however there is no way to express that in CartoCSS.

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Mateusz Konieczny via Tagging



Nov 22, 2020, 17:08 by tagging@openstreetmap.org:

> Likewise we need to stop software developers from expectingcontributors 
> to add data purely because they can't be bothered/notcompetent enough to 
> write a few lines of code. (OSM-carto demandingboundaries on ways)
>
[citation needed] for OSM-carto demandingboundaries on ways

Also [citation needed] for OSM-Carto support for boundary relations being 
extremely easy to implement

>  & numerous routers expecting multiplefoodways to criss-cross pedestrian 
> areas, are just two examples) 
>
Also [citation needed] for that reason is
"can't be bothered/notcompetent enough to write a few lines of code" 

>  If developers are offended at receiving suggestions on how toimprove 
> their software, or even have it criticized, then they shouldrescind it. 
>
If you insult others, claim that something is trivial to implement (it is not),
while something you demand is implemented already and suggest that
anyone offended by your comments should stop releasing software

I would say that it is quite poor way to encourage volunteer
contributors to implement what you want.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] surface=boardwalk? is it duplicate of surface=wood?

2020-11-21 Thread Mateusz Konieczny via Tagging
Is there some value in surface=boardwalk tag?

It seems to be a duplicate of surface=wood.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] surface=rock

2020-11-21 Thread Mateusz Konieczny via Tagging



Nov 21, 2020, 17:43 by o...@westnordost.de:

>> rock „pieces“ would be tagged as „stone“ I guess?
>>
>
> Not so sure about that, then it would be surface=stones, (note the plural) 
> wouldn't it?
>
I am completely fine with both versions.
I created today https://wiki.openstreetmap.org/wiki/Tag:surface%3Drock
where I described surface=rock as fitting for them - but feel free to change 
this

> - Rock implies a rough naturalness
>
+1

> - Steps made of large (single-piece) hewn stone columns would be called 
> 'stone steps'
>
so surface=stone (surface=stones) would be more fitting for them?

> - Bare [rock] implies the lack of rubble on top
>
Small amount: yes
Complete lack of it: no.

See for example https://commons.wikimedia.org/wiki/File:Krywan_podejscie.jpg

Especially for easily eroding rock that is breaking piece by piece some rubble 
will be always
present.

> - Scree is specially loose
>
+1

> - Personally I think bare_rock and stone are synonyms here, unless someone 
> thinks there's a difference.
>
Yes, even if we would invent some differences none would be present in de facto 
usage
(different areas with different differences and subtle distinctions)

> rock = rough natural stone, could be loose stones too
> stone = smooth stone / bare rock, could be hewn
> bare_rock = probably similar to stone, definitely no loose stones
> scree = surface like (large) gravel, natural
> rocky = scree is rocky, piles of differently sized rocks are rocky
>
Overall I think that I am fine with surface=rock, but I am not opposed to also 
other
values (though I am not going to make proposals or wiki pages for them)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Piles of stones

2020-11-20 Thread Mateusz Konieczny via Tagging
Looking at https://en.wikipedia.org/wiki/Cairn it seems that it is
something more purposefully constructed than 
"pile of unwanted stones kept in one place"

Create area and mark as surface=stone ?
man_made=pile_of_stones ?


Nov 20, 2020, 23:32 by graemefi...@gmail.com:

> I was having similar thoughts just a couple of days ago, about what to call a 
> pile of rocks that a farmer has cleared from, then piled up in, a field?
>
> natural=bare_rock says it's exposed bedrock
> =scree has fallen from an adjacent rockface
> =shingle is on a beach or river bed
> =stone is for large boulders
> =rock is "a notable rock feature or small group of rocks, attached to the 
> underlying bedrock"
> none of which really fit?
>
> I did see man_made=cairn as "a mound of stones, usually conical or pyramidal, 
> raised as a landmark or to designate a point of importance in surveying", 
> which also isn't really right, because this isn't for any use apart from 
> getting all the rocks in one place.
>
> Thanks
>
> Graeme
>
>
> On Sat, 21 Nov 2020 at 08:01, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> It seems that we have no good value to mark surface of path of rocky paths.
>>

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


Re: [Tagging] surface=rock

2020-11-20 Thread Mateusz Konieczny via Tagging

Nov 20, 2020, 23:14 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 20. Nov 2020, at 23:01, Mateusz Konieczny via Tagging 
>>  wrote:
>>
>> surface=rock
>> surface=bare_rock
>>
>
>
> these seem both explicit and ok, although bare rock is a bit redundant 
> and rock alone has 5 times the usage: > 
> https://taginfo.openstreetmap.org/tags/surface=rock
>
Both for exposed natural rock and steps/footways made of rock pieces?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] surface=rock

2020-11-20 Thread Mateusz Konieczny via Tagging
It seems that we have no good value to mark surface of path of rocky paths.

surface=gravel fits for surface of small rocks (almost always man made, though
especially in mountains some may be of a natural origin)

surface=fine_gravel fits for small gravel

surface=unhewn_cobblestone =sett =paving_stones for processed rocks

surface=ground is not specific at all (though sometimes useful to avoid 
splitting
way into 191919 parts)

suface=earth / dirt for exposed soil
surface=mud  for exposed soil that is typically full of water

But it seems that we have no tag for exposed rock that ends as surface of path.
It is typical on mountainous trails. See for example:

https://commons.wikimedia.org/wiki/File:Bare_Rock_Trail_Surface_at_Lake_Roland.jpg
https://commons.wikimedia.org/wiki/File:Krywan.JPG
https://commons.wikimedia.org/wiki/File:Krywan_podejscie.jpg

surface=rock
surface=bare_rock ()

there is also case of surface made of unprocessed rocks (typically on trails
with heavy use to protect area from erosion and tourists from mud)
https://commons.wikimedia.org/wiki/File:Hrebienok10Slovakia5.JPG
https://commons.wikimedia.org/wiki/File:Trail_in_Tatra_mountains_paved_with_local_rocks.jpg
surface=rock? other tag?

(some time ago I floated idea of using surface=unhewn_cobblestone for them,
but it was not liked by anyone - 
see https://forum.openstreetmap.org/viewtopic.php?pid=703751#p703751 )
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-20 Thread Mateusz Konieczny via Tagging
I am not a fan of deprecating
pump=manual and replacing it with nearly impossible to remember and less clear
mechanical_driver=manual

Also, this proposal deprecates pump=powered without providing replacement

Now to tag this info one is supposed to select value from
reciprocating_solenoid
combustion_engine
electric_motor
cylinder
turbine

and no way to tag equivalent of pump=powered is provided.

Mapper may be uninterested in or unable to get info about technical detail,
but they should be still able to tag info that pump is not manually operated.

Nov 19, 2020, 20:05 by fl.infosrese...@gmail.com:

> Hi all
>
> Tonight I'm pleased to announce the start of voting for the tagging proposal 
> about pumps
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> A lot of comments lead us to an interesting tagging for pumps devices, water 
> wells and wind pumps. Thank you to anyone involved in this review.
> Some values are proposed to be deprecated as to classify pumps according to 
> their technologies and capabilities.
>
> Several contributors tested the proposed tags in real conditions and no 
> problem seems to remain.
>
> Feel free to give your opinion until December 3
>
> All the best
>
> François
>

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


Re: [Tagging] lanes - is "parking allowed" a parking lane?

2020-11-20 Thread Mateusz Konieczny via Tagging



Nov 20, 2020, 11:47 by dieterdre...@gmail.com:

> Am Fr., 20. Nov. 2020 um 11:28 Uhr schrieb Mateusz Konieczny <> 
> matkoni...@tutanota.com> >:
>
>> This seems unlikely, with 0 lanes it would mean that cars inside are blocked
>> and unable to leave.
>>
>
>
> that's not the meaning of "lanes", lanes=0 would mean that there are no 
> traffic lanes. (this is what the wiki says about "lanes"). 
>
With two parking lanes and 0 traffic lanes cars would be unable to leave, as 
both lanes would
be filled with cars and there would be no space to drive.

If there are two parking lanes and there is still space for a single driving 
lane
then it would be lanes=1 

>> IMHO these are 2 lanes, clearly marked on the ground. I do not see a reason 
>> for one lane to be seen as parking lane only.
>> Even if it is both de facto pernament parking lane and parking in this way 
>> is legal?
>>
>
>
> as long as cars do not have to stop in order to pass each other, yes. I agree 
> the width of the road is restricted, but if opposite traffic can continuously 
> pass, it is 2 lanes according to the current wiki ("how many traffic lanes 
> there are on a highway.")
>
I would also tag as lanes=2

But what about case raised by Tobias where there is no space for that?
https://westnordost.de/misc/2or1lanes.jpg 
https://lists.openstreetmap.org/pipermail/tagging/2020-November/056322.html

> Another question that comes to mind, now that we have removed the requirement 
> for road markings. In a situation where 3 lanes are marked, but vehicles 
> ignore the marked lanes and actually drive in 4 lanes, would you tag this as 
> 3 or 4 lanes?
>
No idea. I would probably treat marking as overriding and tag 3 and invent new 
tag for de facto lane
count.

And probably also petition local government to redraw too wide lanes if that 
would be 
applicable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] lanes - is "parking allowed" a parking lane?

2020-11-20 Thread Mateusz Konieczny via Tagging



Nov 20, 2020, 11:03 by dieterdre...@gmail.com:

> Am Fr., 20. Nov. 2020 um 09:45 Uhr schrieb Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>> I would describe >> https://westnordost.de/misc/2or1lanes.jpg>>  as road
>> with 
>> - one lane driveable by full-size vehicles
>> - one parking lane
>>
>
>
> really? And if vehicles would be parking on both sides (without the explicit 
> roadside parking area that is present in this case), you would tag it as 
> lanes=0 and 2 parking lanes only?
>
This seems unlikely, with 0 lanes it would mean that cars inside are blocked
and unable to leave.

It is not impossible, but is it a typical situation anywhere?

I even mentioned two variants of "two parking lanes":
- two parking lanes on road, one driveable lane, no road markings - I would tag 
as lanes=1
 ( 
https://wiki.openstreetmap.org/wiki/File:Barton_St_view_E_between_South_Park_Rd_and_Brown_St,_Macclesfield.jpg
 )
- two marked lanes, cars parking illegally on both sides, resulting in single 
usable lane
(cars driving over centerline) - is it possible to have this happen legally?
And illegal de-facto parking is problematic in general


> IMHO these are 2 lanes, clearly marked on the ground. I do not see a reason 
> for one lane to be seen as parking lane only.
>
Even if it is both de facto pernament parking lane and parking in this way is 
legal?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] lanes - is "parking allowed" a parking lane?

2020-11-20 Thread Mateusz Konieczny via Tagging
I would describe https://westnordost.de/misc/2or1lanes.jpg as road
with 
- one lane driveable by full-size vehicles
- one parking lane

And tag it as:
lanes=1
parking:lane:both=parallel (judging from what is visible about left side)

Additional detail that I am generally not tagging may specify
for example:

parking:lane:right:parallel=on_street
parking:lane:left:parallel=on_kerb (judging from what is visible on photo)

Tagging whatever parking lane has just allowed parking that fully block it
or is it explicitly marked as parking lane can go into new tag (if not
covered by an existing tagging).

For example I would consider
https://wiki.openstreetmap.org/wiki/File:Barton_St_view_E_between_South_Park_Rd_and_Brown_St,_Macclesfield.jpg
as lanes=1, not lanes=3

-

This gets trickier with:

- illegal parking that nevertheless is accepted, widespread and typical, de 
facto changing
number of available lanes

For example street that in theory is lanes=2 but due to how people park and 
lack of need for two lanes,
it is de facto lanes=1 (cars driving over marked centerline as theoretical 
lanes are blocked
by cars)

- lane that switches between parking lane and driveable lane depending on
hour/day (lanes:conditional solves this)
- lane that switches between parking lane and driveable lane depending on
how many people park there

Nov 19, 2020, 15:17 by o...@westnordost.de:

> Hello all
>
> First of all, in the past, we have explored many edge cases for the lanes-tag 
> in various discussions and I am happy that for the most part, it seems to be 
> quite well defined by now. However, there is one edge case which is not 
> uncommon at all but still unclear or awkward to tag. Look at this:
>
> https://westnordost.de/misc/2or1lanes.jpg
>
> It is a residential road marked clearly for 2 lanes, so it seems obvious to 
> tag it with lanes=2. But on the other hand, you'll notice that there are 
> parking cars on the right side that effectively render the right lane 
> unusable. These parking cars would (currently) be tagged I believe as
>
> parking:lane:right=parallel
> parking:lane:right:parallel=on_street
>
> And the wiki states
>
>> And the following lanes should be excluded:
>> [...] Parking lanes [...]
>>
>
> So here is an ambiguity in the documentation. On the one hand, if the road 
> has marked lanes, the number of marked lanes should be tagged, on the other 
> hand, there are these kind of "parking lanes" which do not have their own 
> space marked as a parking lane but simply absorb the space assigned to normal 
> car traffic. In OSM tagging, these are also "parking:lane"s as far as I know.
>
> We need to dissolve this ambiguity by defining a way how to distinguish 
> between these two cases:
>
> https://westnordost.de/misc/parallel_parking_lane.png
> (1) a dedicated parallel parking lane. This lane should not count as a lane 
> in the lanes-tag.
> (2) (parallel) parking is allowed (and used). This should be irrelevant for 
> the lane count.
>
> My suggestion would be
> (1) parking:lane:*:parallel = lane
> (2) parking:lane:*:parallel = on_street
>
> Maybe especially those who recently involved themselves with parking lane 
> tagging out and about and its documentation could also state their point of 
> view here. According to the wiki edit history, looks like at least Mateusz 
> Konieczny, Supaplex030 and Minh Nguyễn were active.
> What do you think?
>
> There is also at least one data consumer I know about that is using parking 
> lane information and displays it visually,
> https://github.com/dabreegster/abstreet it would be good to know how they 
> interpret and visualize the data.
>
> Cheers
> Tobias
>
> ___
> 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 Cycle Route Relations vs. Ways

2020-11-18 Thread Mateusz Konieczny via Tagging



Nov 18, 2020, 13:02 by tagging@openstreetmap.org:

> Let's encourage people to use the source tag properly rather than cause
> further decay. Or come up with a better solution, which is definitely
> not a changeset comment.
>
Source tag on the changeset.

Supported by all serious editors, if 
https://github.com/openstreetmap/iD/issues/7755
will be implemented it will be also encouraged by all serious editors.

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


Re: [Tagging] Power line going underground

2020-11-09 Thread Mateusz Konieczny via Tagging
You can suggest not complaining in such case by creating a JOSM issue:

see instructions at 
https://josm.openstreetmap.de/newticket


Nov 9, 2020, 21:50 by t...@fitchfamily.org:

> I’ve added those tags. JOSM still complains but if it fits the power line 
> schema better I guess having some editor warnings is okay.
>
> Thank you!
>
>> On Nov 9, 2020, at 11:25 AM, Hidde Wieringa  wrote:
>>
>> 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
>>

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


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

2020-11-09 Thread Mateusz Konieczny via Tagging



Nov 8, 2020, 17:44 by jayands...@gmail.com:

>>> And there should be several specialized layers: general car navigation map, 
>>> sport map for hiking/cycling/skiing, transportation. All of that would be 
>>> possible with vector tiles which are less computationally demanding to 
>>> create.
>>>
>> We already have multiple map styles.
>>
>
> What they mean is that the current map styles run by other providers will not 
> be necessary if we switch to vector tiles. 
>
(1) Only if all people will agree what and how should be included in vector 
tiles.
Due to conflicts between quality and tile size and performance on client and 
different
needs unification is simply impossible and will not happen and should not be 
expected to
happen

For example: hiking trails map vs pipeline map vs focus on small tile size - 
all of that
have completely different needs.

(2) This is nitpicking, but remember that big benefit of vector tiles is that 
you can have own
map style allowing some (limited, not full) changes how map is rendered. 

So number of map styles would increase, not reduce as vector tiles are more 
widely available.

And vector tiles served from OSMF servers would not mean that commercial 
hosting by
companies would become unnecessary - if you meant that by
"current map styles run by other providers will not be necessary"___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-09 Thread Mateusz Konieczny via Tagging
Warning: I am not a lawyer

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).

In the same way as Wikidata is CC0 but not importable into OpenStreetMap
as they include location data systematically copied from various sources,
for example Google Maps.

Nov 8, 2020, 10:10 by tagging@openstreetmap.org:

> 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?

2020-11-09 Thread Mateusz Konieczny via Tagging
Nov 8, 2020, 14:00 by tomasstrau...@gmail.com:

> 2020-11-08, sk, 09:46 Mateusz Konieczny via Tagging rašė:
>
>> (and it is from person who put a lot of effort into tagging improvements, 
>> wikifiddling,
>> deprecating some unwanted values, deduplication and validator-related work 
>> and has
>> some experience from data consumer side)
>>
>
> That is a lie, as you're supporter of harmful duplication of water schema :-D
>
Fact that I do not agree in 100% with Tomas Straupis does not invalidate 
anything 
of what you quoted.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-08 Thread Mateusz Konieczny via Tagging
I really like an idea of separate database/layer for such fuzzy objects.

Especially as there are multiple competing ideas for when specific
object ends and even how many continents/oceans we have.

Nov 8, 2020, 06:51 by tomasstrau...@gmail.com:

> If we're talking about fuzzy features (which do not have specific
> boundaries) like mountain ranges, bays, straits etc. the problem is
> that just a point is not enough, text must have direction, sometimes
> even curvature to follow the geometry of the object ant thus "connect"
> the label with the object in our consciousness. Additionally, for some
> objects, say bays, we need totally different set of labels for
> different zooms and that can only be calculated if we have a polygon
> (check water labels and how they change
> https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with
> zoom 16 there is actually a lot of labels placed in different places
> of the waterbody). But placing polygons for fuzzy objects have
> problems:
>  * borders are not verifiable on the ground (as there is actually no
> border - object is "fuzzy")
>  * imprecisely drawn boundaries of such objects look bad in the
> editor, intersect with other objects and this kind of pushes mappers
> to simply use boundaries of  existing features (like coastlines) which
> makes those object waay too precise for fuzzy objects.
>  My personal opinion is that such objects could be moved to a
> separate database specific to fuzzy objects. That database should not
> have ANY connection to the main database so that mappers would not be
> able to reuse geometries of the main database. Thus license would be
> the same, toolchain would be the same, data could later be used
> alongside the data from the "main" database. Everyone should be happy,
> both arguments (Christophs and Frederiks) against such objects would
> be satisfied?
>
> -- 
> Tomas
>
> ___
> 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] Basic cartography features missing, why?

2020-11-07 Thread Mateusz Konieczny via Tagging



Nov 8, 2020, 05:31 by mach...@gmail.com:

> I absolutely agree with Seth, OSM should switch to vector tiles ASAP. 
>
Note that OSM would not switch to vector tiles. At most one more rendering 
would switch
to vector tiles.

For OSM Carto see 
https://github.com/gravitystorm/openstreetmap-carto/issues/3201
(not sure what is the state and what is the current blocker)

(sorry if that is overly pedantic)

> And there should be several specialized layers: general car navigation map, 
> sport map for hiking/cycling/skiing, transportation. All of that would be 
> possible with vector tiles which are less computationally demanding to create.
>
We already have multiple map styles.

> Their code is all on github so no need to reinvent the wheel and I think this 
> could be easily modified for OSM purposes.
> https://github.com/FreemapSlovakia
>
Is there somewhere description/summary of their software stack?

> If there is nobody who can or is willing to do it then let's hire someone who 
> can. 
>
> Or let a company like Mapbox do it.
>
If someone, anyone is willing to sponsor hosting they can propose to add
their tiles to OSM main site (see 
https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers
)

Though as business of Mapbox is to offer paid hosting of OSM data it is dubious 
that they
would put special effort into competing with themself. Even free tier of their 
products
requires giving credit card details.

>  I would be willing to do regular monthly donations for someone's salary if 
> that makes OSM better and more attractive.
>
I am not sure how one may donate for specific target of vector tiles
(it is also not mentioned at https://wiki.openstreetmap.org/wiki/Donations ). 

donati...@openstreetmap.org is appearing on the page, maybe asking there is
there such possibility would be useful

> I also fully agree with Anders. OSM needs change. There should be some sort 
> of committee with a clear vision that would enforce a unified style of 
> mapping.
>
While central power may be useful and offer some benefits, it is really poor 
place for it.

Either some agreement can be reached and such committee is not needed or they
would make decisions where large part of community disagrees with it.

Except cases where this is absolutely needed, such entity would do more damage
than benefit.

> It is absolutely ridiculous that we have features that are mapped in 2 or 
> more different ways simultaneously e.g. riverbanks or sidewalks... Who is 
> supposed to use and rely on such data?
>
Duplicate tags are mildly irritating while processing, but it is not a serious 
or main problem for
data consumers. 

(and it is from person who put a lot of effort into tagging improvements, 
wikifiddling, 
deprecating some unwanted values, deduplication and validator-related work and 
has
some experience from data consumer side)

>
> Martin
>  
>  
>
>> Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan
>>
>> I actually just found that article about OSM’s problems.
>> One of the major topics mentioned, the fact that OSM acts as a database and
>> not a map, and that this acts as a hinderance to the expansion and
>> development of the project, is very true.
>> As a result, I’ve came to think that implementing Vector tiles should be
>> OSM’s #1 development priority right now. If people who find OSM realize
>> that there’s a lot more data than just the raster images displayed by the
>> standard tile layer, than they will be more likely to contribute and grow
>> the OSM community.
>> We’re all here complaining about computational needs required by rendering
>> servers, but there are some great vector tile implementations that require
>> way less computational needs.
>> Moral of the story: We need Vector tiles.
>> El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger <>> and...@torger.se>> >
>> escribió:
>> > This is great information, I didn't know about your project, very very
>> > interesting. I have recently come to understand the OSM-Carto technical
>> > challenges recently. I haven't given it much of a thought as a casual
>> > mapper for the past two years, just been a bit disappointed with how it
>> > looks.
>> >
>> > I am a programmer in profession though so when taking a deeper look and
>> > though about it I see these challenges.
>> >
>> > However, and this is a big however, I think that the face of
>> > openstreetmap really need to be a cartographic sound map. It's not right
>> > that a style seemingly designed mainly for speedy diagnosis should be
>> > the face of OSM. How many of our mappers are so technical that they
>> > understand this? And howcome did I not even know about this cartographic
>> > project of yours? If there are great styles out there but noone knows
>> > about them that's a problem.
>> >
>> > And even if we let the not-so-good-cartography be the first map we see
>> > on >> openstreetmap.org >>  (which makes no 
>> > sense), some of the other 

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

2020-11-07 Thread Mateusz Konieczny via Tagging
Yes, maps are definitely primary way how OSM data is used.

I just wanted to note that it is not only way how it is used.


Nov 7, 2020, 19:42 by and...@torger.se:

>
> Yes good point. Actually, I don't even know if cartography makes the top ten 
> list of how OSM data is used. Does it?
>
>
> For me personally cartography is *the* thing, and I guess I am guilty for 
> arguing from my own perspective. Sure I use basic road routing capabilities 
> too that stem from the data, but what makes it satisfactory for me to map 
> more than just basic roads (which I indeed do a lot of) is that I see my data 
> resulting in good looking and useful cartography (which today leaves some 
> basic key things to be desired in my humble opinion).
>
>
> On 2020-11-07 16:50, Mateusz Konieczny via Tagging wrote:
>
>
>>  
>>  
>>  
>> Nov 7, 2020, 16:41 by and...@torger.se:
>>
>>> And in the end it's about the resulting map.
>>>
>> Not only, OSM data is also used in other ways.
>>  
>>
>> ___
>> 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] Basic cartography features missing, why?

2020-11-07 Thread Mateusz Konieczny via Tagging



Nov 7, 2020, 16:41 by and...@torger.se:

> And in the end it's about the resulting map.
>
Not only, OSM data is also used in other ways.

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


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

2020-11-07 Thread Mateusz Konieczny via Tagging



Nov 7, 2020, 13:33 by j...@wizmail.org:

> On 07/11/2020 11:13, Walker Bradley wrote:
>
>> Computing power seems to be a constraint struggle without greater 
>> fundraising capacity, so could there be some work done on the rendering 
>> process? Could we do a specific and targeted fundraising effort to improve 
>> the renderer to make as much use of the limited computer power we have?
>>
>
> Alternatively, could the rendering job be done by the client needing the
> out-of-date tile, and resubmitted to the server?
>
(1) you need trusted clients (as client can submit any image and claim that it
is a generated map)
(2) administering thousands of clients is very problematic and time consuming
(3) it existed as tiles@home and stopped existing as noone was interested in
maintaining this

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


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

2020-11-06 Thread Mateusz Konieczny via Tagging
> some of these algorithms could run on GPU clusters these days

No matter where code actually runs you need to have and handle this servers.

For reference basic requirements for a render node include:
80 GB RAM (at least; better 128 GB);
6 or more CPU cores (12+ with HyperThreading, CPU year 2011 or newer eg: Xeon 
X5675);
Storage: 1 TB SSD for database, 1.5 TB HDD (better SSD) for storing tiles;
Fast network connection with high usage or unlimited traffic (at least 30 
TB/month);
( from https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN - requirements
for donated render server)

And yes, with higher budget (for example, with more donated servers) it would 
be a smaller problem.

> the quality of OSM's cartography is held back due to limited server 
> infrastructure.

Note that anyone may develop software for making maps with high quality labels.
It could be running locally/on small areas/very long etc.

I am not involved in this area, but I am not aware about anything either giving 
good results
or reaching some fundamental problems with OSM data format. 
Even dealing with conflicting labels for points, automatic smart dealing with 
long labels and 
multipolygon labelling is as far as I know completely unsolved.

Nov 6, 2020, 23:19 by and...@torger.se:

>
> Sorry for replying to myself, but I forgot to mention one important aspect 
> that I myself hadn't realized until recently: it's seems to be a whole lot 
> about processing power too.
>
>
> Name tag scaling and placement strategies are expensive algorithms compared 
> to what we the default style does now, and I see repeatedly when various 
> improvements to openstreetmap-carto is discussed that "the idea is good and 
> would improve the style, but is unfortunately too computationally expensive 
> so it's not feasible". I suspect that least some of the naming falls into 
> that category, especially when doing smart things when zooming out to give 
> good overview maps.
>
>
> I have not understood why there are these CPU limits, if it's "just" due to 
> under-financed server infrastructure, or if it is a problem that can't be 
> solved regardless of server infrastructure. As a layman one would think that 
> some of these algorithms could run on GPU clusters these days, but I have no 
> idea... it feels a bit problematic though if the quality of OSM's cartography 
> is held back due to limited server infrastructure.
>
>
> /Anders
>
>
> On 2020-11-06 22:51, Anders Torger wrote:
>
>
>>
>> I'd love to help out if the workload and chance of success was reasonable, 
>> but I'm a bit wary about the tagging proposal process. Most of my mapping 
>> contributions is simple things like correcting and adding roads so all the 
>> various online route planners (and indeed bike computers) that use OSM in 
>> one way or another can work in the areas I spend time. For that the map does 
>> not need to be complete at all, I just need a graph of roads, and I use the 
>> regular government-provided maps to actually scout the area.
>>
>>
>> Recently I got more interested in trying to make actual complete and good 
>> cartography, make maps that accurately describes the area (to a certain 
>> detail level) and doesn't require "a real map" on the side for scouting, in 
>> other words make OSM to be a real map in the areas I live. It would also be 
>> nice if one could make hiking maps for the mountains. This is an extremely 
>> ambitious goal, in Scandinavia, and probably many more countries, we are 
>> used at having really great cartography from a special cartography institute 
>> which is a part of the government. Previously the maps were expensive to get 
>> and you could only get it on paper. Today the main aspects exists for free 
>> in digital form (which is a good thing, it's made with tax payers' money 
>> after all). Here, this is the gold standard for a general-purpose map.
>>
>>
>> However, when I see there are some key features missing in OSM to be able to 
>> reach that level, and each of those little features may take years of 
>> processing from proposal to actual implementation in a renderer (and even if 
>> a proposal goes through, I suppose it's not guaranteed that it may be 
>> implemented), then it feels like it's just too much for me, as I'm involved 
>> in many other volunteer projects too. Mapping is not even my main project.
>>
>>
>> To make this happen it seems like I will end up with having to implement my 
>> own style and have my own tile server and using my own tags... it's just not 
>> feasible. What I have done so far in my own mapping applications which works 
>> sort of fine is to use ready-made government maps in a custom layer for the 
>> more zoomed out map (and indeed have an own tile server for that), and then 
>> switch to OSM for the most zoomed in levels. The limitations in name 
>> handling and missing names for large areas is less noticed when fully zoomed 
>> in. But it would be really cool if one could use OSM for the whole 

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

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 23:10 by dieterdre...@gmail.com:

> Am Fr., 6. Nov. 2020 um 21:04 Uhr schrieb Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>>> ** Support for group naming is limited. It's here very common that several 
>>> smaller islands are named as a group, smaller ponds are named as a group 
>>> etc, without having individual names. There are tags for that 
>>> (group/cluster), but not rendered. 
>>>
>> Mostly because multipolygons are strictly superior.
>>
>
>
> for groups, the group relation is clearly superior. First of all, it implies 
> group semantics and is defined. For a multipolygon, it may not be clear what 
> it is about, unless you invent tags for "a group of lakes", a group of ponds, 
> a group of trees, a group of island. 
>
The same if true for group. There is no semantic difference in creating 
group/cluster/site relation
and tagging with name and creating multipolygon and tagging it with name.

If you want to distinguish "group of islands" from "group of lakes" in both 
cases you need
additional tag or special processing.

> But still, it only works for areas, you cannot use multipolygons for groups 
> of nodes or groups of lines, or mixes of these.
>

Yeah, multipolygons are superior for for cases like mentioned - set of areas.

If you want group of nodes/ways then sadly it stops being a great solution.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 23:39 by and...@torger.se:

>
> One example is making a multipolygon instead of the semantically superior 
> group, as multipolygon actually renders.
>
>
Why multipolygon is supposed to be semantically inferior?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 19:31 by and...@torger.se:

> Hello everyone, newcomer here!
>
> I've been a casual contributing mapper for a couple of years here in Sweden. 
> Only since 2018 :-O, I thought it was longer, and during this time I've made 
> 1700 edits mostly using iD, just started using JOSM for some more complex 
> edits. Anyway, I recently tried to up my game to make really high quality and 
> "complete" maps in the areas I live. 
>
Hello! This type "lets completely do XYZ" tends to reveal 
unfinished/missing/problematic parts.

I hope that my answers will explain a bit situation and at least partially 
answer your questions.

> I'm not 100% sure if this mailing list is the right venue for discussing 
> these issues. 
>
It sounds that most of that is about tagging so I would say "yes"

> ** Tagging and naming areas on ground does not seem to be developed much at 
> all, unfortunately.
>


> ** There is natural=peninsula so one can tag and name an area of varying 
> size, but it doesn't seem to render (unless I've made some mistake...)
>
With less than 1000 mapped lack of support is not surprising. Not sure is there 
a better tag/way
to map this. If not, then simply mapping more of them is a good idea.

https://taginfo.openstreetmap.org/tags/natural=peninsula


> ** I can't make an area to name hills or slopes, which is very common around 
> here (natural=hill would be nice and is more generic than slope). There's 
> peak, but that's only for point for the highest peak with elevation, so it 
> doesn't the purpose here.
>
Using natural=peak for hill should be fine.

For slopes: is it name for part of slope? Farmland area on it? Entire hill? 
Something else?

I used for example https://www.openstreetmap.org/way/259975428 - I was lucky
as name applies just to farmland area.

> ** Valleys can only be tagged as ways, but here it would make much more sense 
> to make an area, as sizes of these valleys vary a lot, and the renderer need 
> to know how large this is (not just how long) to make sane renders.
>
You can tag valleys as areas. Are you maybe using iD (in-browser editor)? 

Note that iD has its own presets suitable for newbies, but it is perfectly fine 
to use
tagging schemes not included in iD.

(note: some people have developed strong opinions how bays, valleys etc should 
be tagged)

>
> ** Due to limitations in area-based name tagging the map looks empty just 
> when zoomed out a little, as names disappear almost directly, so despite 
> detailed mapping and tagging the overview map is not as useful as it could 
> be. 
>
Note that it depends on a renderer. It is possible to make smarter that will 
keep names for longer
if possible.

>
> While the renderer can and does make proper decisions of prominence for bays 
> and strait made as areas, point-based natural names often yield strange and 
> misleading maps as vastly different sized areas have just a point for the 
> name and no other differentiator, there's no way the renderer can make an 
> appropriate render decision as the data is not there.
>
What specific you have in mind? I admit that for example for peaks rendering is 
often poor,
but data for local importance (elevation) is there. But making automatic smart 
renderer is
tricky at best.

> ** Support for group naming is limited. It's here very common that several 
> smaller islands are named as a group, smaller ponds are named as a group etc, 
> without having individual names. There are tags for that (group/cluster), but 
> not rendered. 
>
Mostly because multipolygons are strictly superior.

> The best alternative today is to make it a named multipolygon, but only few 
> renderers make the expected result, ie one name rather than only in one 
> subarea or duplicated in all areas (which looks strange as the name is often 
> in plural form, or it doesn't show up at all if each subarea is small).
>
This is basically on the renderer side, I am unsure what can be improved here 
on data side.

> ** Another fairly common group naming concept is when each feature has its 
> own name, but the group of features have also a separate collective name. 
> Maps supporting this concept will thus when you zoom out not show the 
> individual names but only the group name. The group/cluster tag would perhaps 
> be the way to do this, but as far as I know no current style supports it.
>
Yes, this one is unsolved.

> ** As a minor note, I've noted there is no good tag for anonymous gravel 
> yards, which there are a lot of here. Abandoned quarry is the closest, but 
> still not right, as only some actually were gravel/sand pits to start with. 
> Those gravel yards are often leftovers from construction work or forestry 
> often even locals don't exactly know when or why they were made. Today they 
> are used mainly used for parking by people being out in nature, but they are 
> not maintained so they are not exactly parking lots either.
>
I would make a new separate thread for that and link some pictures 

Re: [Tagging] What is a saltbox?

2020-11-06 Thread Mateusz Konieczny via Tagging

Feb 12, 2020, 20:39 by o...@lepiller.eu:

> Le 12 février 2020 14:26:26 GMT-05:00, Michael Brandtner via Tagging 
>  a écrit :
> >Hi,
> >we have a big inconsistency between different wiki pages and editors
> >how we define the roof shape "saltbox". 
> >1) A saltbox is a roof with a tilted part at left and right side and a
> >flat part on top. This definition can be found at:
> >https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
> >It is used for example in the presets of the Vespucci editor. 
>
>>
>>
> >2) A saltbox is a roof with only one tilted part (usually directed at
> >the road) and one flat part on top. On the other side it goes straight
> >down. The roof shape described at 1) is a double_saltbox.
> >This definition can be found
> >at:https://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table
>
>>
>>
> >This definition is for example used by the StreetComplete editor.
>
>>
>>
> >This is a serious issue, because it means that for none of the over
> >3,000 buildings with the tag roof:shape=saltbox we can know which shape
> >it actually has.
>
>>
>>
> >Cheers,Michael
>
> Also for some reason, this tag is different from what wikipedia describes a 
> saltbox to be: > https://en.wikipedia.org/wiki/Saltbox_house
>
I edited https://wiki.openstreetmap.org/wiki/Template:Roof:shape to note the 
problem
what is visible on https://wiki.openstreetmap.org/wiki/Key:roof:shape
and https://wiki.openstreetmap.org/wiki/Simple_3D_buildings

If someone cares about roof:shape values the best solution would be to propose 
new
values for involved shaped and deprecate saltbox value.

 (I am certainly not going to do this, may TODO list is far too long to do this
even if I would live until AD 2650).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread Mateusz Konieczny via Tagging
heritage, heritage:operator, ref:??? appear to be used to tag official heritage 
status

See https://wiki.openstreetmap.org/wiki/Key:heritage


Nov 6, 2020, 09:26 by jez.nichol...@gmail.com:

> I believe that a key point is that these threshing floors have protected 
> status in Portugal and Spain due to their historical significance. The 
> suggestion of using 'historic[al]' is to represent this. 
>
> In other parts of the world, where it is in current use and not 
> ancient/protected then perhaps it is an 'amenity'?
>
> Is there a subtag to distinguish an historical/protected amenity from a 
> straight/unprotected one?
>
>
> On Thu, 5 Nov 2020, 23:08 António Madeira via Tagging, <> 
> tagging@openstreetmap.org> > wrote:
>
>> Yes, as I said in the previous message, it was my misunderstanding.Sorry 
>> about that.
>>  
>>  
>>  
>> Às 20:02 de 05/11/2020, Mateusz  Konieczny escreveu:
>>
>>> I was referring to
>>>
>>> "
>>> I see there's a reference to this feature in this<>>> 
>>> https://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties>>> 
>>> >wiki page, but wouldn't it fit better in the man_made tag? After all,this 
>>> is still an used feature, although not always with the original intent.
>>> "
>>>
>>>
>>> Nov 5, 2020, 19:55 by >>> tagging@openstreetmap.org>>> :
>>>
>>>> I didn't get it, Mateusz. 
>>>> What does historic=wayside_shrine have to do with  threshing floor?
>>>>
>>>>
>>>>
>>>>
>>>>>>> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via  
>>>>>>> Tagging <>>>>>>> tagging@openstreetmap.org>>>>>>> >  
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> We also have historic=wayside_shrine that is
>>>>>>>> used for ones that are not historic at all.
>>>>>>>>
>>>
>>>
>>
>> ___
>>  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 - electricity=*

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 01:03 by elga...@agol.dk:

> Joseph Eisenberg:
>
>> Generally OpenStreetMap data is not updated frequently enough by mappers and 
>> database users for us to map temporary states (e.g. anything which lasts 
>> less than 6 months). Many database users will download a data extract for 
>> offline use and only update this every 3 months or so - see Maps.me for 
>> example, and perhaps facebook's  use of OpenStreetMap data.
>>
>
>
> I agree.
> But there are some interesting cases around that 6 month range.
>
> For example we now have access:covid19
>
>
> Another example is road work on motorways. That can easily take 6 month to a 
> year. First they do one side and have both directions share the lanes of what 
> was earlier one direction. Then they do the other side.
>
> Sometimes mappers change the speed limit to e.g. 60 km/h, but usually when 
> the work is finally done, it takes a long time for someone to put it back at 
> 130.
>
> It would be useful to be able to tag a temporary speed limit with an 
> estimated expiry date. And maybe an estimated start date for offline maps.
>
See https://wiki.openstreetmap.org/wiki/Conditional_restrictions

motor_vehicle:conditional=no @ (2018 May 22-2018 Oct 7)
maxspeed:conditional=60 @ (2021 May 22-2021 Oct 7)

This will self-terminate even if nobody will remember to remove tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag a threshing floor

2020-11-05 Thread Mateusz Konieczny via Tagging
I was referring to

"
I see there's a reference to this feature in 
this<https://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties>wiki 
page, but wouldn't it fit better in the man_made tag? After all,this is still 
an used feature, although not always with the original intent.
"


Nov 5, 2020, 19:55 by tagging@openstreetmap.org:

> I didn't get it, Mateusz. 
>  What does historic=wayside_shrine have to do with threshing floor?
>  
>  
>  
>
>>>> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via  Tagging 
>>>> <>>>> tagging@openstreetmap.org>>>> >  wrote:
>>>>
>>>>>
>>>>> We also have historic=wayside_shrine that is usedfor 
>>>>> ones that are not historic at all.
>>>>>

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


Re: [Tagging] How to tag a threshing floor

2020-11-05 Thread Mateusz Konieczny via Tagging



Nov 5, 2020, 18:22 by tagging@openstreetmap.org:

>
>
>
> Nov 5, 2020, 13:56 by pla16...@gmail.com:
>
>> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via Tagging <>> 
>> tagging@openstreetmap.org>> > wrote:
>>
>>>
>>> We also have historic=wayside_shrine that is used for ones that are not 
>>> historic at all.
>>>
>>
>> Those are tagging errors, then.
>>
> What would be even correct tag for them? I agree that situation is suboptimal,
> but it was predictable result of defining tag for some sublass of shrines and 
> ignoring others.
>
To clarify: I consider that in case of historic=wayside_shrine usage redefined 
tagging
and it means "it is a shrine", not "it is a historically significant shrine of 
a specific type"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag a threshing floor

2020-11-05 Thread Mateusz Konieczny via Tagging



Nov 5, 2020, 13:56 by pla16...@gmail.com:

> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>> We also have historic=wayside_shrine that is used for ones that are not 
>> historic at all.
>>
>
> Those are tagging errors, then.
>
What would be even correct tag for them? I agree that situation is suboptimal,
but it was predictable result of defining tag for some sublass of shrines and 
ignoring others.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag a threshing floor

2020-11-05 Thread Mateusz Konieczny via Tagging
Note that 
https://taginfo.openstreetmap.org/tags/historic=threshing_floor#chronology
indicates that most of uses were likely imported.

We also have historic=wayside_shrine that is used for ones that are not 
historic at all.

Overall man_made=threshing_floor seems OK, though tagging also 
historic=threshing_floor
for old ones seems fitting.

Nov 5, 2020, 00:11 by tagging@openstreetmap.org:

> Greetings.
>  
>  In Portugal and all Mediterranean countries, there are thousands of > 
> thresing  floors > . Most 
> of them are not used anymore, of course, but theyare still preserved and 
> are private spaces used for many purposes. Imyself have one.
>  I see there's a reference to this feature in > this 
> >  
> wiki page, but wouldn't it fit better in the man_made tag? Afterall, this 
> is still an used feature, although not always with theoriginal intent.
>  
>  Regards.    
>

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


Re: [Tagging] religious bias - Re: Feature Proposal - Voting - (Chapel of rest)

2020-11-05 Thread Mateusz Konieczny via Tagging



Nov 4, 2020, 21:46 by t.pfei...@computer.org:

> I was surprised that this tag is rushed into voting despite the arguments 
> against it even here in the tagging list discussions.
>
Any typical longer discussion on tagging mailing list will have arguments 
against any position.


> * 27 Sep: 'Chapel of Rest' seems to be one of those terms like 'Take the goat 
> to the butcher...
>
What is it even supposed to mean/imply?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-05 Thread Mateusz Konieczny via Tagging



Nov 5, 2020, 09:43 by woll...@posteo.de:

> Thanks for all the interventions.
>
> To avoid that the discussion becomes inconclusive again, could everybody rate 
> the following "favourable", "acceptable" or "unfavourable"?
>
> amenity=mourning
>
unfavourable (unclear)

> amenity=place_of_mourning
>
unfavourable (likely to be misinterpreted by nonnative speakers)

> amenity=mourning_room
>
favourable

> amenity=viewing_arrangements
>
unfavourable (seems unrelated to funeral)

> amenity=deceased_viewing
>
favourable, though sounds a bit silly

>
> Am 04.11.2020 11:17 schrieb woll...@posteo.de:
>
>> Dear all,
>>
>> As there have been no more comments for some time on this proposal,
>> I've set it to voting. Please have a look and vote:
>>
>> Chapel of rest: a room or building where families and friends can come
>> and view someone who has died before their funeral
>>
>> Proposal page:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest
>>
>> Discussion page:
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest
>>
>> Thanks!
>>
>> Vollis
>>
>
> ___
> 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 - electricity=*

2020-11-03 Thread Mateusz Konieczny via Tagging
Note in some regions where blackout are often happening it
is quite typical to have both grid connection and backup 
generator.

Is it also typical in hospitals, some factories and other places
where power loss would be especially problematic (what includes
also for example dams, even ones with their own hydro-power generators).

Nov 3, 2020, 14:08 by lrich...@posteo.de:

>
> Hi,
>
>
> While the original proposal did specify that generators are  usually 
> diesel, broadening the definition would only lead to a  loss of detail, 
> but the tagging would still be correct. I'm  hesitant to use > offgrid>  
> as a building that has, for  example, a grid connection with solar panels 
> on the roof would  then be tagged as > electricity=grid;offgrid>  instead 
> of > electricity=grid;generator> .  The former is illogical. 
>
>
> However, I don't have any experience in developing countries: is  it 
> easier to verify if something is off-grid compared to if it is  connected 
> to a generator? And, would it be necessary to  differentiate between 
> local grids (i.e. 2-3 generators, no  substations, transfromers, etc.) 
> and national grids? Perhaps then  a network tag would be useful, i.e. 
> network=national, local,  regional similar to the way cycle networks are 
> mapped?
>
>
> A further suggestion was to change the tagging to>  > 
> electricity:grid=yes/no/backup>  and/or > 
> electricity:generator=yes/no/backup> . This might be  less ambiguous for 
> tagging amenities or buildings that get  electricity from both sources 
> and would then be more consistent  with tagging such as > 
> electricity:generator:origin=diesel>  when, e.g. a building has a backup 
> diesel generator but is  connected to the grid. Unfortunately, it would 
> then not be  consistent with the use by the Healthsites Mapping Project,  
> although this already has the inconsistent > electricity=none>  tag which 
> should probably be changed directly to > electricity=no.>  
>
>
> Cheers, Lukas
>
>
>
>
> On 03/11/2020 07:14, Dolly  Andriatsiferana wrote:
>
>> Hi all, 
>>
>> Thanks a lot Lukas for reworking this proposal.
>>
>> I like Joseph's idea of >> electricity=grid/offgrid/yes/no>>  if  
>> you're introducing >> electricity:origin=>> *. 
>> I'd suggest dropping the generator value as it brings  confusion and 
>> can be difficult to verify. Originally  electricity=generator seemed 
>> to be intended for diesel  devices, but I think we should use 
>> something like  electricity:origin=diesel for it instead.
>>
>> @Volker, I understand the tag might be less relevant in  developed 
>> countries where it is normal to have electricity.  But electricity 
>> availability is an important information in  many developing 
>> countries (like mine) where most of the  population is not connected 
>> to the electricity grid. It would  be useful for health facilities 
>> and accommodation buildings...  - See Healthsites' data model at >> 
>> https://wiki.openstreetmap.org/wiki/Global_Healthsites_Mapping_Project>>  
>> where the tag is used.
>>
>> Good job, Lukas!
>>
>> -->>  
>> Dolly Andriatsiferana
>>
>> On Tue, Nov 3, 2020 at 4:11 AM  Lukas Richert <>> 
>> lrich...@posteo.de>> > wrote:
>>
>>>
>>> And, final email, I reworked the proposal page to include  
>>> tagged examples and explained some implicit defintions in  more 
>>> detail.
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/electricity
>>>
>>>
>>> Cheers
>>>
>>>
>>>
>>>
>>> On 30/10/2020 13:44, Lukas Richert wrote:
>>>

 Since a lot of people apparently didnt see the RFC the
 first time, I'll go back to RFC status for now. (Ithought 
 the threads were sorted by subject title of theemail and 
 didnt check online if it was actually visible.)


 --


 The original message: 



 Hello all, 
  
  after the comments on the confusing nature of the word
 'source' in my original proposal of'electricity:source', I 
 have now changed the name to'electricity:origin' as 
 suggested on the discussionpage. Furthermore, I would like 
 to revive and extend theproposal of the key 'electricity' 
 as this previouslyconflicted with parts of the 
 electricity:source proposaland was not consistent. 
  
  Both proposal pages: 
  
  [1]  
 https://wiki.openstreetmap.org/wiki/Proposed_features/electricity  
  
  [2]  
 

Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

2020-10-28 Thread Mateusz Konieczny via Tagging
access=no should be enough, if parking searcher is not handling 
access=no/access=private
it is broken anyway


Oct 28, 2020, 09:19 by lrich...@posteo.de:

>
> I think here it would better to use the primary name space of  emergency, 
> similar to disused/abandoned, so that routers/data  providers that don't 
> consider this tag won't lead people to park  there.
>
> On 28/10/2020 05:21, Mateusz Konieczny  via Tagging wrote:
>
>>
>>
>>
>> Oct 28, 2020, 03:22 by >> andrew.harv...@gmail.com>> :
>>
>>> On Wed, 28 Oct 2020 at 13:20, Jonathon Rossi<>>> 
>>> j...@jonorossi.com>>> >wrote:
>>>
>>>> We've got emergency=landing_site for  helicopters, maybe 
>>>> just emergency=parking?
>>>>
>>>
>>> I like that, areas set aside for parking by emergency  
>>> vehicles. 
>>>
>>
>> amenity=parking access=no emergency=yes
>> seems a better fit to me
>>
>> ___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 from fire_service_areas - landuse:emergency

2020-10-28 Thread Mateusz Konieczny via Tagging
I that case amenity=parking would not fit.

I thought that "areas set aside for parking by emergency vehicles" would be 
parking
with special restrictions (and some of them exist, for example hospitals or 
healthcare
locations may have dedicated parking spaces or entire parking lots reserved for 
emergency vehicles,
https://www.openstreetmap.org/way/407300815 is an internal parking of a fire 
station and so on).

Oct 28, 2020, 09:39 by supap...@riseup.net:

>
> "parking" should not be used for this, because in many cases  these areas 
> have nothing in common with a parking lot. This  meadow, for example, is 
> explicitly a rescue area, but definitely  not a parking lot: > 
> https://www.openstreetmap.org/way/503246160>  (and I think, by the way, that 
> in case of an emergency it's not  just about "parking", but also setting 
> up equipment, turning  vehicles around etc.)
>
>
> In my opinion the key "emergency" is perfect for such cases.
>
>
> For the use at roads, however, there is  "parking:lane: = 
> fire_lane" if a lane is designated  like this.
>
>
>
>
> Am 28.10.20 um 06:21 schrieb Mateusz  Konieczny via Tagging:
>
>> Oct 28, 2020, 03:22 by >> andrew.harv...@gmail.com>> :
>>
>>> On Wed, 28 Oct 2020 at 13:20, Jonathon Rossi <> >>> j...@jonorossi.com>>> > 
>>> > wrote:
>>>
>>>> We've got emergency=landing_site for helicopters, maybe just 
>>>> emergency=parking?
>>>>
>>> I like that, areas set aside for parking by emergency vehicles. 
>>>
>> amenity=parking access=no emergency=yesseems a better fit to me
>>
>> ___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 from fire_service_areas - landuse:emergency

2020-10-27 Thread Mateusz Konieczny via Tagging



Oct 28, 2020, 03:22 by andrew.harv...@gmail.com:

> On Wed, 28 Oct 2020 at 13:20, Jonathon Rossi <> j...@jonorossi.com> > wrote:
>
>> We've got emergency=landing_site for helicopters, maybe just 
>> emergency=parking?
>>
>
> I like that, areas set aside for parking by emergency vehicles. 
>

amenity=parking access=no emergency=yes
seems a better fit to me
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] What does bicycle=no on a node means?

2020-10-21 Thread Mateusz Konieczny via Tagging



21 Oct 2020, 22:00 by tagging@openstreetmap.org:

> On 16/10/2020 09:31, Mateusz Konieczny  wrote:
>
>> Oct 15, 2020, 22:18 by >> tagging@openstreetmap.org>> :
>>
 This recent wiki change by  Emvee 
   is in my view not 
 helpful,  or even misleading, as it does discourage a wide-spread  
 tagging practice (if we like this or not is a different  
 question, but it's established tagging, and the wiki is  supposed 
 to describe the establsihed methods of tagging)

>>>
>>> The change describes what a router does with bicycle=no on a  node, 
>>> see >>> https://github.com/abrensch/brouter/issues/265
>>>
>>>
>> No, you changed documented meaning of tagging scheme in
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dcrossing=revision=2043653=2025128
>>
>> OSM Wiki is not describing only tagging that is supported.
>>
>> Note that it is fine to describe tagging as problematic,unsupported 
>> and having a better alternative.
>>
>
> Rereading what was added the text describes exactly what is  problematic 
> namely bicycle=no in the context of routing. I did not  add that context 
> but that is something I can do. 
>
>
> Adding that mapping the crossing from curb to curb as separate  osm way 
> with the correct access tags is a better alternative is a  good idea.
>
>
>>>
>>> Already discussed elsewhere but having routers ignore  bicycle=no 
>>> in combination with highway=crossing means that it  is more or less 
>>> useless as routers are they main data  consumers while at the same 
>>> time crossing data is far from  being complete.
>>>
>>>
>> Any tagging scheme is for some period unsupported, this doesnot make 
>> it useless.
>>
> If data is not used and will not be used in the foreseeable future Icall 
> it useless.
>> And any widely used tagging scheme can be described. Asobvious from 
>> this discussion meaning
>> of this bicycle=no is clear so I will revert your edits onthis page
>>
>
> I do not see how you came to this conclusion, but as I noted on  the Talk 
> page I have no problem with reverting for now but think  it should be 
> reverted further to point before bicycle=no/yes was  added.
>
>
Why?
>
> Instead of reverting you could have chosen for the changes I did  point 
> out above.
>
>
>>>
>>> My take is that it is not a wide-spread tagging practice and  it 
>>> does not add new information as weather it is a pedestrian  issue 
>>> can be deduced from the connecting ways.
>>>
>>>
>> Not in cases where 
>> (1) highway=cycleway is crossing road where cyclists areobligated to 
>> dismount
>> (2) highway=footway with bicycle=yes/designated is crossingroad 
>> where cyclists
>> are obligated to dismount
>>
> Can be covered by mapping the crossing, curb to curb as separate osmway. 
> A bit more effort but more precise.
>
Yes. But the entire thread was started due
to wiki edit redefining already tagged data.

I am open to describing way splitting as
preferable, but not to redefining existing tagging.
>  
>
>>
>> (3)pedestrian only crossing is tagged on road having cyclewayon both 
>> sides 
>> (tagged as cycleway:lef/cycleway:right/cycleway:both) 
>> (or where such road has cycleway at one side, is joined byseparately 
>> mapped 
>> cycleway from other side and there is crossing there, but
>> cyclists must dismount)
>>
>
> There is no need to tag this type of "solitary" crossing for  routing 
> purposes, a router will never want to make a turn half way  the road. 
>
>
But given road may be obstacle to be crossed
with user desiring to get to other side
>
> So these "solitary" crossings are useless in routing  context while 
> routers do have problems with bicycle=no/dismount on  a node.
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] OSM changes the world | Re: Feature Proposal - RFC - Artificial

2020-10-21 Thread Mateusz Konieczny via Tagging



Oct 21, 2020, 09:49 by r...@technomancy.org:

> On Wed, 21 Oct 2020, at 6:25 AM, Mateusz Konieczny via Tagging wrote:
>
>> (4) I would prefer to not use OSM as a tool
>> to change language, especially if done at 
>> cost of making more complicated for
>> mappers. AFAIK term "man made" and it's
>> meaning remains standard and is well 
>> understood
>>
>
> The purpose of OSM is to change the world. We're trying to create a map of 
> the world, build by enthusiastic local people and to give it away to everyone 
> for free. We're trying to produce a geo commons for every person. It's too 
> late to say that OSM shouldn't change anything in the world. 
>
I wrote "I would prefer to not use OSM as a tool to change language".

I see this proposal as similar to "we should use Esperanto as language for name 
tag"
that appeared some time ago.

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


  1   2   3   4   5   >