Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-26 Thread pangoSE
Hi

Matthew Woehlke  skrev: (25 augusti 2020 15:25:19 
CEST)
>On 24/08/2020 16.25, pangoSE wrote:
>> Martin Koppenhoefer skrev: (24 augusti 2020 02:16:27 CEST)
>>> Also useful when the POI is approximately placed (e.g. in a
>>> neighbouring building, happens quite often, at least as long as most
>>> POIs are not yet mapped)
>> 
>> Really? Can you link to an example?  I have never come across a POI
>> that needed a special address. I would rather map to he entry in the
>> that case and put the address there.
>
>Just about any strip mall. For example, 42.8625, -73.7831. I can give
>at 
>least three other examples within 1000 *feet*; in a few miles, probably
>
>a dozen or more.
>
>Mapping stores in such cases practically requires mapping the *insides*
>
>of the buildings. It's much more typical to drop a POI in about the 
>right place (either the middle of the store, or the entrance to the 
>store). Yet, these *do* have distinct addresses.
>
>The same can easily happen with multi-unit dwellings.
>
>Also, mailboxes have addresses, but are unlikely to be mapped as ways 
>due to their size.
>
>> The POI IMO cannot logically have an address itself, its a human 
>> symbol for designating something of interest within a feature like a 
>> building, park or whatever.
>
>...or its a somewhat abstracted representation of a building because no
>
>one has yet made the effort to map the building more precisely. BTW, 
>it's not that unusual for detached houses to be mapped as POIs, 
>especially when addresses are imported from GIS data that gives them 
>only as points. Yes, in an ideal world everything of this nature would 
>be mapped as a way, but that isn't always practical.
>
>> When the Swedish geosurvey sometime soon release all public adresses
>> for free we will have to merge them all with the buildings where
>> possible.
>...And what will you do if there is no building, and it isn't obvious 
>how to add one (e.g. strip malls)? Not import that address at all?
>
>> thinking about it postal addresses follows land plots and legal
>boundaries and not POIs.
>
>Actually, AFAIK this is only partly true. Yes, the address "123 Cherry 
>Lane" follows a plot, but I'm not aware of anything preventing me from 
>erecting three structures on that plot and designating them "unit 1", 
>"unit 3.14" and "unit gamma". This would be unusual on a residential 
>plot, but not at all (well, sans my intentionally bizarre numbering)
>for 
>a commercial building.

I rest my case. Thanks for the examples. Could you help update the wikipage 
about POIs to reflect this?

Cheers 

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


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-25 Thread pangoSE


Martin Koppenhoefer  skrev: (25 augusti 2020 09:18:08 
CEST)
>
>
>sent from a phone
>
>> On 25. Aug 2020, at 02:07, pangoSE  wrote:
>> 
>> What I mean is that its a bad idea to keep the exact same data in
>multiple places and thinking about it postal addresses follows land
>plots and legal boundaries and not POIs.
>
>
>it is often not the exact same data. Housenumbers could be distinct 13
>and 14 while the POI address would be 13-14 (or 13;14 if you prefer).

Oh, in that case it SGTM. 
Could you update the wiki if it is not clearly stated somewhere already?

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


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-24 Thread pangoSE
Hi

Andrew Harvey  skrev: (25 augusti 2020 00:39:55 CEST)
>On Tue, 25 Aug 2020 at 06:27, pangoSE  wrote:
>
>> The POI IMO cannot logically have an adress itself, its a human
>symbol for
>> designating something of interest within a feature like a building,
>park or
>> whatever. Adresses are specialized designations used by the state and
>> postal service. You cannot apply for an address for a newsstand, a
>> phonebooth or a park (In Sweden)
>>
>
>By that logic (at least in Australia) the building cannot have an
>address,
>after all here land parcels hold the address not the building, but we
>still
>commonly tag the building or POI with an address since they "hold" the
>address.

Yeah, its probably the same here because you can have a land plot without a 
house but with a postbox and address anyway.  It is a compromise to put it on 
the buildings where they exist because land plots is out of scope.

What I mean is that its a bad idea to keep the exact same data in multiple 
places and thinking about it postal addresses follows land plots and legal 
boundaries and not POIs.

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


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-24 Thread pangoSE
Hi Martin

Martin Koppenhoefer  skrev: (24 augusti 2020 02:16:27 
CEST)
>
>
>sent from a phone
>
>> On 23. Aug 2020, at 23:20, pangoSE  wrote:
>> 
>> This collides with one feature one element does it not?
>
>
>it does not. An address is not (necessarily) a feature, it can also be
>a property 

Hmm. I don't buy that argument. If that is a valid argument you could have 
copies of data in many places in OSM say all tags on a way could be added to 
each node as well for "stability". The problem is that it is a unnecessary 
burden IMO to maintain of.

>
>
>> Can you give an example of what you mean by stable?
>
>
>if you move the POI or the building geometry, the (surveyed) POI
>address is still explicitly tagged.

Why would anyone do that?

>
>Also useful when the POI is approximately placed (e.g. in a
>neighbouring building, happens quite often, at least as long as most
>POIs are not yet mapped)

Really? Can you link to an example?  I have never come across a POI that needed 
a special address. I would rather map to he entry in the that case and put the 
address there. 

The POI IMO cannot logically have an adress itself, its a human symbol for 
designating something of interest within a feature like a building, park or 
whatever. Adresses are specialized designations used by the state and postal 
service. You cannot apply for an address for a newsstand, a phonebooth or a 
park (In Sweden)

In Sweden the postal system works only with physical places designated by 
Lantmäteriet as a legal piece of ground. You cannot assign an adress yourself 
to a random area in the forest for example no matter if it has a world famous 
POI or not.

The Swedish community has decided that we add addresses to buildings and 
entries instead of having points (like in Denmark). When the Swedish geosurvey 
sometime soon release all public adresses for free we will have to merge them 
all with the buildings where possible. I hope they will give all their adress 
nodes unique, permanent IDs to help us synchronize in the future.

Cheers 

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


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-24 Thread pangoSE
Hi Cj

Cj Malone  skrev: (23 augusti 2020 
23:56:33 CEST)
>> Not exactly a very user-friendly system though, especially if you're
>> only trying to review requested changes?
>> 
>> & with somewhere between 300k - 600k changes sitting there to look
>> at, I don't think the chances are all that high that somebody will
>> spot any errors!
>
>On the face of it I agree, it's a non obvious system and and reviewing
>changesets should be encouraged more. I would consider myself an
>advanced mapper now, and I've never reviewed a changeset. I never even
>knew how to.
>
>However as an anecdote, the current system seems to work, when I
>requested a review of my first 3D building I not only got one, but it
>got fixed. [1] [2]
>
>Cj
>
>[1] https://www.openstreetmap.org/changeset/70583513
>[2] https://www.openstreetmap.org/changeset/70610688

Thanks for sharing. that's nice to hear. I think we should make it dead simple 
to monitor how many reviews are done.
A checkbox titled "this a review" would be a very nice addition IMO if stored 
in a Boolean column in the database it could be easily counted how many cs have 
requested and gotten reviews. 

I'll try if I can get together with others here in Sweden to review more. Its 
always more fun to do stuff together. 

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


Re: [Tagging] Benches and hostile architecture

2020-08-24 Thread pangoSE
Hi

Vucod via Tagging  skrev: (24 augusti 2020 15:43:37 
CEST)
>Just to clarify an important point. The hostile_architecture key was
>suggested as a main/category tag to go along with specific keys
>(lying_hindrance, sitting_hindrance).
>Used alone, I agree that it would be very vague and could be difficult
>to verify. I would say to only use it in combination with specific keys
>but I don't know how this would be followed by mappers...

I think this is a bad idea. Someone wanting to list all examples of hostile 
architecture could do it using the other tags you mentioned.  Hostile is biased 
and not verifyable and should be avoided IMO.

/pangoSE 

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


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-23 Thread pangoSE


Martin Koppenhoefer  skrev: (23 augusti 2020 19:15:04 
CEST)
>
>
>sent from a phone
>
>> On 23. Aug 2020, at 18:53, Thibault Molleman
> wrote:
>> 
>> Should that entrance node also have the 
>> addr:housenumber=15
>> tag or is it assumed based on it being placed on the building's way?
>
>
>The addr:housenumber ideally should be added to the object to which it
>applies (polygon like building, entrance, gate, etc.). It will
>typically not be necessary to repeat it if the topology already makes
>the feature part of an object with the same addressing information, but
>some mappers (myself included) prefer repeating the address on POIs
>because it makes the data more stable.

This collides with one feature one element does it not? Can you give an example 
of what you mean by stable?

Cheers

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


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread pangoSE
Hi Shawn 

"Shawn K. Quinn"  skrev: (23 augusti 2020 19:01:53 CEST)
>On 8/22/20 23:53, pangoSE wrote:
>> And we have no statistics or functionality to mark a changeser as
>> revieed so nobody knows how many reviews are done and how many falls
>> through the cracks. We could make a tool that lists all changesets
>> with a review request and no comments.
>
>Good idea. I'd like to add that a new mapper's first changesets should
>probably be reviewed, even if a review is not requested. I do this for
>greater Houston, time permitting.

I agree. The tool could highlight that as well. 

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


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-22 Thread pangoSE
Hi

"Jarek Piórkowski"  skrev: (23 augusti 2020 00:41:40 CEST)
>On Sat, 22 Aug 2020 at 18:12, Clifford Snow 
>wrote:
>> On Sat, Aug 22, 2020 at 3:06 PM Graeme Fitzpatrick
> wrote:
>>> Reading through it though, I noticed though that he used iD, &
>ticked the box "I would like someone to review my edits", which
>apparently didn't happen at the time?
>>>
>>> Question though - if an iD mapper asks for someone to review their
>edits, where does that appear?
>>>
>>> Does it just sit on the map like a Note or a Fix Me, or is there a
>report of some sort sitting somewhere to be processed?
>>
>> osmcha.org picks up the review request. Their interface makes it easy
>to view and post a comment back to the user.
>
>Having said that, it is my impression that realistically a big
>majority of review_requested=yes changesets never get a review. I
>remember checking it on several of my changesets and never heard
>anything.

And we have no statistics or functionality to mark a changeser as revieed so 
nobody knows how many reviews are done and how many falls through the cracks. 
We could make a tool that lists all changesets with a review request and no 
comments.

I also tested it and never heard anything. I dislike it because it gives a new 
user the impression we review and have a good follow up process which we 
generally don't (in Sweden).

>
>This might depend on the location of the edit too, similarly to how
>OSM.org Notes have different resolution rates worldwide.
>
>(Not picking on anyone, I've also never done a review)

I have done a lot of reviews for new swedish edits during some time. It was 
very rewarding to contact new mappers in the area and offer them a helping hand 
actually.

I found the edits via thia external tool: 
http://resultmaps.neis-one.org/osm-suspicious#0/7/21
I'm  not recommending we use it though and I'm hesitant to sharing it here 
because it is not free software. If some of you know the author please contact 
him and ask him to release the source.


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


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-22 Thread pangoSE
Hi Mateusz

Thanks for the link.
I agree that forcing someone to map is a bad idea.


Mateusz Konieczny via Tagging  skrev: (22 augusti 
2020 10:54:57 CEST)
>Also, his was poorly organized Organised Editing and  this person was
>forced
>to map in OSM by badly designed university assigment.
>
>If anything that is proof that forcing people to map in OSM is even
>less useful
>than expected.
>
>( according to
>https://www.gizmodo.com.au/2020/08/we-tracked-down-the-person-responsible-for-the-flight-simulator-melbourne-monolith/
>)
>
>
>Aug 22, 2020, 10:51 by me-osm-tagg...@keepawayfromfire.co.uk:
>
>> On Sat, 2020-08-22 at 09:32 +0200, pangoSE wrote:
>>
>>> Building upon it can lead to strange things. E.g. 
>>>
>https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
>>>  (building:levels=212 was entered erroneously and committed to the
>>> database without any kind of QA follow-up. If someone knows the
>>> osmid I would like to know how long this error was present in OSM)
>>>
>>
>> https://www.openstreetmap.org/way/712475718/history
>>
>> 1 - It was introduced by a novice mapper, presumably as a typeo.
>>
>> 2 - Nikolas von Randow fixed it about 9 months later, presumably with
>> some kind of QA tool (maybe just a overpass query).
>>
>> 3 - Another local novice mapper also edited it, and fixed another
>issue
>> at the same time. Presumably noticed via a rendered map.
>>
>>
>> Before criticising the mapper, it should be noted that it was a
>novice
>> mapper and the existing building data in the area isn't of great
>> quality anyway. This wasn't a regression. And accidents happen
>anyway,
>> I've done a similar thing via StreetComplete where I entered the
>house
>> number in the building levels quest.
>>
>> The big companies doing QA on OSM data (Mapbox and Facebook) have a
>> high focus on vandalism. They are trying to stop "Jewtropolis" from
>> ever happening again.
>>
>>
>>
>> ___
>> 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] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-22 Thread pangoSE
Thanks for sharing. I have no intention of contacting the user in question. It 
was just an illustrative example.

I don't know why this was posted to the tagging list. I intend to keep this 
discussion on the talk list so please respond there to keep the discussion 
together.


Cj Malone  skrev: (22 augusti 2020 
10:51:10 CEST)
>On Sat, 2020-08-22 at 09:32 +0200, pangoSE wrote:
>> Building upon it can lead to strange things. E.g. 
>>
>https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
>>  (building:levels=212 was entered erroneously and committed to the
>> database without any kind of QA follow-up. If someone knows the
>> osmid I would like to know how long this error was present in OSM)
>
>https://www.openstreetmap.org/way/712475718/history
>
>1 - It was introduced by a novice mapper, presumably as a typeo.
>
>2 - Nikolas von Randow fixed it about 9 months later, presumably with
>some kind of QA tool (maybe just a overpass query).
>
>3 - Another local novice mapper also edited it, and fixed another issue
>at the same time. Presumably noticed via a rendered map.
>
>
>Before criticising the mapper, it should be noted that it was a novice
>mapper and the existing building data in the area isn't of great
>quality anyway. This wasn't a regression. And accidents happen anyway,
>I've done a similar thing via StreetComplete where I entered the house
>number in the building levels quest.
>
>The big companies doing QA on OSM data (Mapbox and Facebook) have a
>high focus on vandalism. They are trying to stop "Jewtropolis" from
>ever happening again.
>
>
>
>___
>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] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-22 Thread pangoSE
Hi

80hnhtv4agou--- via talk  skrev: (22 augusti 2020 
03:06:37 CEST)

> 
>Also there is no wiki on unverified edits.
> 

In OSM we don't yet have an established system for verification or accurate 
machine readable references for the data to my knowledge.

This means the whole database is basically just a mess of biased data that one 
of our millions of editors thought should be included. Most objects have very 
few revisions and we have no idea about the overall quality or correctness. It 
a playground with half-ass quality more than an authoritative and verified 
source of information (like e.g. Wikipedia). Building upon it can lead to 
strange things. E.g. 
https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
 (building:levels=212 was entered erroneously and committed to the database 
without any kind of QA follow-up. If someone knows the osmid I would like to 
know how long this error was present in OSM)

We should really fix this and start a verification effort after implementing a 
sane verification model.

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


Re: [Tagging] Have our tagging voting rules changed recently?

2020-08-04 Thread pangoSE
I agree.

Colin Smale  skrev: (4 augusti 2020 11:26:30 CEST)
>On 2020-08-04 10:06, Andrew Harvey wrote:
>
>> I'd suggest that if you vote no, it will be helpful for the community
>if you could elaborate on why you're voting no, without enforcing a
>reason as mandatory. Is it because this feature shouldn't be mapped, is
>it because there is an alternative tag. So if the vote fails all this
>feedback can be taken onboard for a revisal of the proposal and second
>round of voting.
>
>The explanation should possibly have been given earlier, during the
>consultancy phase? In a vote, the only thing that should count towards
>the outcome is how you vote, not why you voted that way. All votes have
>equal weight, irrespective of their motivation. 
>
>However, in the ensuing inquest it is obviously useful to understand
>why
>a proposal was not supported by many people.. For that matter, it is
>also useful to know what made people support it as well. 
>
>Putting a proposal to the vote should IMHO not be done unless the
>discussions are clearly pointing towards approval. A vote is not a
>substitute for the discussion, it should be a confirmation that
>consensus has been achieved.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

2020-08-04 Thread pangoSE
Thanks for the heads up Joseph. I also read what Imagico wrote1 and voted no.
I recommend others to do the same.

Cheers 
pangoSE
1 
https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposed_features/Ground=253931=2016970=2016363

Joseph Eisenberg  skrev: (3 augusti 2020 23:17:18 
CEST)
>Everyone, the voting period for natural=bare_ground is still open for 4
>more days.
>
>I would recommend voting "no" on the current definition, unfortunately.
>
>As mentioned above, the current definition is far too broad, and could
>easily be construed to include areas under construction, areas of bare
>soil
>due to use by people as a pathway or road area, and many sorts of arid
>and
>semi-natural areas, including those that are partially covered by
>shrubs,
>heath, grass or other sparse vegetation, or even areas of farmland that
>are
>currently fallow.
>
>Please see the discussion and objections on
>https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground
>
>I think it is a good idea to have a way to tag bare soil which is not
>sand
>(natural=sand) or mostly stones (natural=shingle/scree) or mud, but we
>need
>a clear, limited definition which does not fit with human-use areas
>like
>roads, dirt parking lots, construction sites, abandoned quarries etc,
>and
>there needs to be more consideration about when the tag should be used
>instead of natural=heath and natural=scrub in arid regions where there
>are
>scattered bushes.
>
>For the proposal author, I would suggest mapping some local features in
>your area which would fit the proposed definition, and then come back
>with
>photos plus aerial imagery of the areas which ought to be mapped with
>this
>tag. So far it has been mostly hypothetical, which makes it hard to
>understand which sorts of landscapes would qualify for this tag.
>
>- Joseph Eisenberg
>
>On Mon, Jul 27, 2020 at 5:58 AM Martin Koppenhoefer
>
>wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 27. Jul 2020, at 13:41, Michael Montani 
>> wrote:
>> >
>> > I eventually found on-the-ground images of the feature I would like
>to
>> propose / map.
>>
>>
>> are these suggested to be represented as polygons? How would the
>border be
>> determined? I looks from the imagery as if there is a smooth
>transition of
>> these „features“ and neighbouring land which isn’t completely bare.
>Did you
>> try to map some of these and if yes, could you please post a link to
>an
>> area where a few are mapped?
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-25 Thread pangoSE
Fine by me to attach them to whatever.
I would not map them twice.

Anyway I never met or heard about anyone who wanted to navigate to a signpost. 
Usually people navigate to attractions like a lake or a firepit or a viewpoint 
or simple follow a route and walk past the guideposts.
I find them sometimes rotten/broken and whatever so with a digital map in hand 
they are not really needed. Certainly not needed in the route relations for 
routing purposes.
There might be a stastical usecase like "which route has the most signposts per 
km?" But aside from that they are irrelevant aside from being visible on the 
map as any kind of man-made thing you pass by like a building or mast.
If someone really wants to I'm sure you can tweat a query in postgresql to 
output all signposts along a path within x meters from the path without needing 
to have them in any relation.

Martin Koppenhoefer  skrev: (22 juli 2020 20:19:16 CEST)
>
>
>sent from a phone
>
>> On 22. Jul 2020, at 17:10, pangoSE  wrote:
>> 
>> I suggest you add the guidepost to a node on the path instead.
>
>
>I am mapping guideposts rather rarely, when I do it, I place them on
>their actual position, sometimes on building outlines, or on retaining
>walls, or just flying in space. I would not want them on the highway.
>Sometimes at near-crossroads there is a single post for 4 ways, but in
>the details it is 2 T-crossings a few meters apart. With your proposal
>you would have to use 2 OpenStreetMap guideposts where there is only
>one in reality.
>
>Cheers Martin 
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-22 Thread pangoSE
Bad practice if you ask me. Where do we limit what POI is nice to add? I have 
seen huts and shelters and viepoint and buildings added to routes in Sweden. It 
completely botches up the height profiling by data consumers like waymarked 
trails and the calculation of route length becomes harder.

I suggest you add the guidepost to a node on the path instead. 

I really think it would be nice to be able to say query and list all hotels, 
wilderness huts and shelters within 200 m of the Kungsleden trail (Swedens most 
famous trail) but I don't think adding them to relations is the way forward. 
Maybe this can already be done with overpass. At least JOSM can download 
information along a way so it should be possible to implement.

Cheers 
PangoSE

Martin Koppenhoefer  skrev: (22 juli 2020 14:04:25 CEST)
>Am Di., 21. Juli 2020 um 21:39 Uhr schrieb pangoSE
>:
>
>> Andy Townsend  skrev: (21 juli 2020 13:31:45 CEST)
>> >On 21/07/2020 12:04, Michal Fabík wrote:
>>
>> >
>> >I've also been trying to add these (both guideposts and route
>markers)
>> >to the relevant hiking route relation.
>>
>> That does not sound right to me. Why would you do that? A route
>relation
>> is in my mind for ways or relations of ways that make up the path.
>Nothing
>> else.
>
>
>
>it is common practise, at least in some areas. "Why"? Because it is a
>way
>to connect the guideposts to the route. It also seems logical that the
>route consists also of these posts.
>
>Cheers
>Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-21 Thread pangoSE


Andy Townsend  skrev: (21 juli 2020 13:31:45 CEST)
>On 21/07/2020 12:04, Michal Fabík wrote:

>
>I've also been trying to add these (both guideposts and route markers) 
>to the relevant hiking route relation.

That does not sound right to me. Why would you do that? A route relation is in 
my mind for ways or relations of ways that make up the path. Nothing else.

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


Re: [Tagging] Automated edit of image tags suggestion

2020-06-26 Thread pangoSE
thanks for the constructive suggestions :)

Den Thu, 25 Jun 2020 22:14:21 +0200
skrev Re: [Tagging] Automated edit of image tags suggestion:

> sent from a phone
> 
> > On 25. Jun 2020, at 19:59, pangoSE  wrote:
> > 
> > image=File:* -> commons_file=File:* image=Category:* ->
> > commons_category=Category:*
> > image=https://commons.wikimedia.org/wiki/File:* ->
> > commons_file=File:*
> > image=https://commons.wikimedia.org/wiki/Category:* ->
> > commons_category=Category:*  
> 
> 
> splitting commons into files and categories (different keys) seems to
> be an improvement, although neither of these keys are existing at the
> moment. Following what we have so far, “wikimedia_commons_file” and
> “wikimedia_commons_ category“ would fit better, although a bit
> unwieldy.

Fixed in algorithm 2 in the wiki.
https://wiki.openstreetmap.org/wiki/Automated_edits/pangoSE#Key%3Aimage

> 
> From a datauser perspective, does it really improve the situation?

Yes. Commons image-urls can be specified so that a certain size is
returned. If the commons-url is in the image-tag I have to first match
it with a regex, which is an extra step. Some image tags have multiple
urls also which also has to be dealt with, etc. Its a mess from a
dataconsumer viewpoint. 
I experienced it myself making this:
https://github.com/pangoSE/sheltermap

> Right now you have to check for 2 “main” keys: image and
> wikimedia_commons (leaving wikidata out for the moment), and then you
> can see what you find in the value (url, file: category: etc.) after
> your proposed edit you would have to check for more keys but could
> hope that the values would be better standardized. And you’d have to
> run a bot frequently to keep things “clean”.

Is there anything preventing us from running bots (with simple
algorithms) on the database? Wikimedia projects do that all the time. I
rarely see this in OSM (besides the http/https bot)

> 
> Btw, there are also a few images tagged with a “flickr” key (~1200)
> While it could eventually make sense to make an exception for
> wikimedia commons, I do not believe we should create a new key for
> every image hosting service.

For me there are 2 categories: sites hosting free images like
Flickr, Mapillary and Commons and all the rest. All the rest can be in
the image tags. The 3 before mentioned should be kept in their tag if
not for other reasons for statistical purposes.

I'm not advocating creating any more tags for other services here.

Cheers pangoSE

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


[Tagging] Automated edit of image tags suggestion

2020-06-25 Thread pangoSE



 Originalmeddelande 
Från: pangoSE 
Skickat: 25 juni 2020 19:49:58 CEST
Till: tagg...@lists.openstreetmap.org
Ämne: Automated edit of image tags suggestion

Below is a copy of the text at: 
https://wiki.openstreetmap.org/wiki/Automated_edits/pangoSE#Key:image


Key:imageEdit

There are serious problems with the use of this key in the database. 

I recently started discussing the problems related to urls and File:filename.* 
that links to wikimedia_commons using the tag. See 
Talk:Key:image#Discourage_linking_to_commons_files_and_migrate_all_File:filename..2A_values_and_direct_urls_to_wikimedia_commons
 and tagging. 

Algorithm 1Edit image=File:* -> wikimedia_commons=File:* image=Category:* -> 
wikimedia_commons=Category:* image=https://commons.wikimedia.org/wiki/File:* -> 
wikimedia_commons=File:* image=https://commons.wikimedia.org/wiki/Category:* -> 
wikimedia_commons=Category:*

There are some image= tags that link to multiple images separated by ";". These 
will be manually migrated to contain only one image that is not linking to 
commons and the rest in a note, note1, noteX if multiple urls. 

There are some elements like https://www.openstreetmap.org/node/674919702 that 
both link to a commons category with wikimedia_commons= and an additional 
image= that links to one of those images. I will not touch this as it would 
probably be best to introduce new tags commons_image and commons_category for 
this usecase like Yurik did in the tagging discussion. 

There are some urls that link to a category and the media viewer. This is not 
always working (see [1]) but will not be touched by this edit as there have not 
been a discussion of this practice yet to my knowledge. 

Algorithm 2Edit 

Based on suggestions by Yurik of separating the file and category references. 

image=File:* -> commons_file=File:* image=Category:* -> 
commons_category=Category:* image=https://commons.wikimedia.org/wiki/File:* -> 
commons_file=File:* image=https://commons.wikimedia.org/wiki/Category:* -> 
commons_category=Category:*

Note commons_file could also link to a video. 

There are some image= tags that link to multiple images separated by ";". These 
will be manually migrated to contain only one image that is not linking to 
commons and the rest in a note, note1, noteX if multiple urls. 

There are some elements like https://www.openstreetmap.org/node/674919702 that 
both link to a commons category with wikimedia_commons= and an additional 
image= that links to one of those images. These will be changed to commons_file 
and commons_category. 

There are some urls that link to a category and the media viewer. This is not 
always working (see [2]) but will not be touched by this edit as there have not 
been a discussion of this practice yet to my knowledge. 

Affected featuresEdit 

This edit will affect about 80,000 elements in the database. There are >80,000 
image= tags with links to wikimedia commons where 50,000 of them is in Germany 
alone. 

ExecutionEdit 

Changesets will be kept small ie. country size bbox maximum. For Germany there 
are ~50150 so there I will keep the bbox region sized. 

I will use JOSM to make the changes using find/replace. 

DiscussionEdit 



Discussion  

 





        

Last edited 5 months ago by PangoSE 



OpenStreetMap Wiki  

Content is available under Creative Commons Attribution-ShareAlike 2.0 license 
unless otherwise noted.


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


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-27 Thread pangoSE

Does it matter what I as a swede think?

If the tourists/officials visiting speaking Swiss High German(among each 
other) choose to call this city that its fine by me. If the city ever 
translate their homepage to de-ch I suppose they would call it the same.


Names are (in my view) socially constructed and constantly agreed upon 
by the users of the language. I don't speak Swiss High German so I'm not 
really in a position to judge what to call this city in that language. 
IMO OSM is not a suitable place for speakers of Swiss High Germanto 
argue what to call the city for reasons laid out here 
http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/. 



This is very different from a street name that appears on a sign IMO, 
which is verifiable and can be seen by anyone in the same spot.


pangoSE

On 2020-03-27 10:47, Simon Poole wrote:


Just using the entry for your place, do you really think that an entry 
like say


Swiss High GermanHärnösand

makes sense? (Swiss High German is de-CH).

Simon

Am 27.03.2020 um 10:07 schrieb pang...@riseup.net:

Hi Simon.

Do you have a link? The Municipality I live in has sensible names in 
WD https://www.wikidata.org/wiki/Q3240427


Does it matter to us in OSM if it "has the name"? I'm thinking that 
we outsource all the naming to WD to deal with and fight over.
In OSM we could instead concentrate on e.g. what language codes to 
display on osm.org e.g. name_osm=sv for a city with dominant Swedish 
population and name_osm=se for a town/city where most are Sami.
In the case of double naming on the ground we could have something 
like: name_osm= code1 / code2

Where code1 is the e.g. the Welsh and code2 is the English name.

The idea in these cases is the we get rid of all other name tags that 
can be stored and curated better in WD.


On March 25, 2020 10:48:45 PM GMT+01:00, Simon Poole  
wrote:


Note that lots of the wikidata names are nonsense and are simply
derived from the wikipedia page name (which a wp page has to
have, but it doesn't imply that the object actually has a name in
the language of the wikipedia you are looking at). For example
the municipality I live in has a German and a Swiss-German name,
it -doesn't- have names in any of the other 31 languages that are
listed.

Simon

Am 25.03.2020 um 11:00 schrieb pang...@riseup.net:

Honestly I don't think it makes sense for OSM to have names at
all on objects which has a Wikidata reference. We are just too
small a community to keep this updated and it has little value
to duplicate to the efforts made by others.
If any names I suggest we have a bot autoupdating all name tags
according to the values in Wikidata. If there is no Wikidata
item it should be found/created.
It really is'nt hard to populate a map with geographical data
from OSM and query the names the user wants to see from WD.
This offloads a huge burden as I see it.
All our tools that currently invites our users to include a name
could be adapted so that the user is aware that OSM is about
geodata and names are for WD and best stored/updated there.
If we allow a name to be set only when no qid we avoid the bulk
of these problems.
When a qid is set a bot could remove all names for languages
already present in WD.

On March 25, 2020 10:45:03 AM GMT+01:00, Andrew Hain
 wrote:

Why on earth would we not (excluding exceptional copyright
issues) want to have lots of different name:XX tags?

--
Andrew


*From:* Frederik Ramm 
*Sent:* 25 March 2020 09:26
*To:* Tag discussion, strategy and related tools

*Subject:* [Tagging] Which languages are admissible for
name:xx tags?
Hi,

the "name:xx" tags are something of an exception in OSM
because while we
defer to "local knowledge" as the highest-ranking source
normally, this
is not being done for name:xx tags. It is possible for no
single citizen
of the city of Karlsruhe to know its Russian name, but still
a Russian
name could exist. Who is the highest-ranking source for that?

My guess is that about 5% of name:xx tags in OSM actually
represent a
unique name in its own right; all others are either copies
of the name
tag ("this city does not have its own name in language XX
but I want
every city to have a name:xx tag so I'll just copy the name
tag"), or
transliterations (or, worst case, even literal translations).

A while ago we had a longer discussion about Esperanto
names; in that
discussion, it was questioned whether Esperanto could be in
the name tag
but nobody disputed tha

Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-27 Thread pangose
Thank you very much for writing that post. I wholeheartedly agree with your 
arguments. 
 
On the basis of this it makes even more sense to sidestep the name issues and 
leave the battle to wikidatans. We just map what is on the ground and they 
fight over the rest with references, judgements of sources, etc. 


On March 25, 2020 4:47:51 PM GMT+01:00, Christoph Hormann  
wrote:
>On Wednesday 25 March 2020, Jyri-Petteri Paloposki wrote:
>>
>> I slightly disagree with this one. IMO a name in a foreign language
>> would be admissible if it is recognised by native speakers of the
>> language either back home or in the local community OR if the name is
>> otherwise regarded correct by mainstream media or a language
>> authority.
>
>Yes, that line of reasoning is fairly widespread among mappers - 
>considering secondary sources of information as valid sources of 
>information for OSM and not requiring local verifiability but settling 
>for compatibility with the major consensus narrative of the mapper's 
>culture.
>
>I have written in more detail about the problems of this idea some time
>
>ago in
>
>http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/
>
>-- 
>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


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-27 Thread pangose


On March 25, 2020 2:08:33 PM GMT+01:00, Paul Allen  wrote:
>On Wed, 25 Mar 2020 at 10:02,  wrote:
>
>> Honestly I don't think it makes sense for OSM to have names at all on
>> objects which has a Wikidata reference.
>>
>
>Not all mappable objects have a Wikidata reference.  Cities and big
>towns,
>yes.
>Villages and hamlets, most but not all.  Even where a wikidata
>reference
>exists,
>not all languages are given, even when some are actually used by
>locals.

Would it be a problem to add them to WD?

>
>I live in Wales.  Wales is multilingual, Welsh and English.  For some
>hamlets
>and villages there is no English Wikipedia page, just a Welsh one.  The
>Wikidata items for Welsh-only Wikipedia pages often have only the Welsh
>name.
>The road signs have both Welsh and English on them.
>
>Some of the small hamlets don't have a Wikipedia page at all, and no
>Wikidata
>item either.

This is not a problem, it could be created down the road by you or someone 
else. Until then we keep the names as we currently do.

>
>There is no Wikidata item for the short street around the corner from
>me.
>Its
>road sign says "Heol Napier / Napier Street" (the "/" isn't on the
>sign, I'm
>using it to represent a line break).  If that sign were replaced, it
>might
>instead say "Heol Napier Street."  There are a lot of mappable objects
>which don't have Wikidata items yet require names in at least two
>languages just to satisfy the people that live there on a permanent
>basis.
>
>We can't rely on Wikidata in multilingual localities.

I disagree. We could even add a property to WD stating the name on the ground, 
e.g. in your example "Heol Napier / Napier Street"

We could even model the newline by making two ranked statements.
local_name_on_ground=Heol Napier + rank=1
local_name_on_ground=Napier Street + rank=2

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


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-27 Thread pangose


On March 25, 2020 11:50:15 AM GMT+01:00, Phake Nick  wrote:
>在 2020年3月25日週三 18:34,Frederik Ramm  寫道:
>
>> Hi,
>>
>> On 25.03.20 11:19, Phake Nick wrote:
>> > My guess is that about 5% of name:xx tags in OSM actually
>represent a
>> > unique name in its own right; all others are either copies of
>the
>> name
>> > tag ("this city does not have its own name in language XX but I
>want
>> > every city to have a name:xx tag so I'll just copy the name
>tag"), or
>> > transliterations (or, worst case, even literal translations).
>> >
>> > Isn't that the function of the key?
>>
>> Unsure which of my list items you mean - copying the original name is
>> not the function of the key; a data user can simply fall back to the
>> name tag if no name:xx is given. Making a transliteration is also not
>> the the function of the key, since transliterations can be automated.
>> Making a translation is *certainly* not wanted!
>>
>
>How can a data consumer know that whether end user of a certain
>language is
>going to understand the original language?
>And transliteration cannot be automated. There are many specific rules
>and
>exceptions when transliterting place names in different language
>software.
>There are already some OSM-based software that would offer automatic
>transliteration but their results are far from being usable. Making
>translation is *absolutely essential* for people from different part of
>the
>world to make use of OSM data. Last time when I was travelling in some
>foreign nations, I have to give up using OSM because of poor coverage
>of
>translated name for my language in that country which make me unable to
>understand what the OSM map is saying.
>

Could you elaborate on this? I would like an example object that you tried 
navigating to and failed. 

Thanks in advance.

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


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-27 Thread pangose
Hi Simon.

Do you have a link? The Municipality I live in has sensible names in WD 
https://www.wikidata.org/wiki/Q3240427

Does it matter to us in OSM if it "has the name"? I'm thinking that we 
outsource all the naming to WD to deal with and fight over.
In OSM we could instead concentrate on e.g. what language codes to display on 
osm.org e.g. name_osm=sv for a city with dominant Swedish population and 
name_osm=se for a town/city where most are Sami.
In the case of double naming on the ground we could have something like: 
name_osm= code1 / code2
Where code1 is the e.g. the Welsh and code2 is the English name.

The idea in these cases is the we get rid of all other name tags that can be 
stored and curated better in WD.

On March 25, 2020 10:48:45 PM GMT+01:00, Simon Poole  wrote:
>Note that lots of the wikidata names are nonsense and are simply
>derived
>from the wikipedia page name (which a wp page has to have, but it
>doesn't imply that the object actually has a name in the language of
>the
>wikipedia you are looking at). For example the municipality I live in
>has a German and a Swiss-German name, it -doesn't- have names in any of
>the other 31 languages that are listed.
>
>Simon
>
>Am 25.03.2020 um 11:00 schrieb pang...@riseup.net:
>> Honestly I don't think it makes sense for OSM to have names at all on
>> objects which has a Wikidata reference. We are just too small a
>> community to keep this updated and it has little value to duplicate
>to
>> the efforts made by others.
>> If any names I suggest we have a bot autoupdating all name tags
>> according to the values in Wikidata. If there is no Wikidata item it
>> should be found/created.
>> It really is'nt hard to populate a map with geographical data from
>OSM
>> and query the names the user wants to see from WD.
>> This offloads a huge burden as I see it.
>> All our tools that currently invites our users to include a name
>could
>> be adapted so that the user is aware that OSM is about geodata and
>> names are for WD and best stored/updated there.
>> If we allow a name to be set only when no qid we avoid the bulk of
>> these problems.
>> When a qid is set a bot could remove all names for languages already
>> present in WD.
>>
>> On March 25, 2020 10:45:03 AM GMT+01:00, Andrew Hain
>>  wrote:
>>
>> Why on earth would we not (excluding exceptional copyright
>issues)
>> want to have lots of different name:XX tags?
>>
>> --
>> Andrew
>>
>>
>
>> *From:* Frederik Ramm 
>> *Sent:* 25 March 2020 09:26
>> *To:* Tag discussion, strategy and related tools
>> 
>> *Subject:* [Tagging] Which languages are admissible for name:xx
>tags?
>>  
>> Hi,
>>
>> the "name:xx" tags are something of an exception in OSM because
>> while we
>> defer to "local knowledge" as the highest-ranking source
>normally,
>> this
>> is not being done for name:xx tags. It is possible for no single
>> citizen
>> of the city of Karlsruhe to know its Russian name, but still a
>Russian
>> name could exist. Who is the highest-ranking source for that?
>>
>> My guess is that about 5% of name:xx tags in OSM actually
>represent a
>> unique name in its own right; all others are either copies of the
>name
>> tag ("this city does not have its own name in language XX but I
>want
>> every city to have a name:xx tag so I'll just copy the name
>tag"), or
>> transliterations (or, worst case, even literal translations).
>>
>> A while ago we had a longer discussion about Esperanto names; in
>that
>> discussion, it was questioned whether Esperanto could be in the
>> name tag
>> but nobody disputed that adding name:eo tags is ok, even though
>> Esperanto is an invented (or "constructed") language.
>>
>> Yesterday someone added a few dozen Klingon names to countries in
>> OSM. I
>> have reverted that because of a copyright issue, but I think we
>also
>> need to discuss which languages we want to accept for name:xx
>tags.
>>
>> In my opinion, a name:xx tag should only be added if you can
>> demonstrate
>> that people natively speaking the living language xx are actually
>> using
>> this name for this entity. I think we have a very unhealthy
>> inflation of
>> names in OSM that are added by "single-purpose mappers" - they
>> come in,
>> stick a name:my-favourite-language tag onto everything, and go
>away
>> again. Nobody knows if these names are even correct, and nobody
>cares
>> for their maintenance. The country North Macedonia changed its
>name
>> almost one year ago, yet roughly half of its ~ 170 name tags are
>still
>> what they were before this change. Nobody cares; these names
>suggest a
>> data richness that is not backed up by an actual living community
>that
>> cares for them.
>>
>> What are your opinions on which languages should be 

Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-25 Thread pangose
Honestly I don't think it makes sense for OSM to have names at all on objects 
which has a Wikidata reference. We are just too small a community to keep this 
updated and it has little value to duplicate to the efforts made by others. 
If any names I suggest we have a bot autoupdating all name tags according to 
the values in Wikidata. If there is no Wikidata item it should be found/created.
It really is'nt hard to populate a map with geographical data from OSM and 
query the names the user wants to see from WD.
This offloads a huge burden as I see it.
All our tools that currently invites our users to include a name could be 
adapted so that the user is aware that OSM is about geodata and names are for 
WD and best stored/updated there.
If we allow a name to be set only when no qid we avoid the bulk of these 
problems. 
When a qid is set a bot could remove all names for languages already present in 
WD.

On March 25, 2020 10:45:03 AM GMT+01:00, Andrew Hain 
 wrote:
>Why on earth would we not (excluding exceptional copyright issues) want
>to have lots of different name:XX tags?
>
>--
>Andrew
>
>
>From: Frederik Ramm 
>Sent: 25 March 2020 09:26
>To: Tag discussion, strategy and related tools
>
>Subject: [Tagging] Which languages are admissible for name:xx tags?
>
>Hi,
>
>the "name:xx" tags are something of an exception in OSM because while
>we
>defer to "local knowledge" as the highest-ranking source normally, this
>is not being done for name:xx tags. It is possible for no single
>citizen
>of the city of Karlsruhe to know its Russian name, but still a Russian
>name could exist. Who is the highest-ranking source for that?
>
>My guess is that about 5% of name:xx tags in OSM actually represent a
>unique name in its own right; all others are either copies of the name
>tag ("this city does not have its own name in language XX but I want
>every city to have a name:xx tag so I'll just copy the name tag"), or
>transliterations (or, worst case, even literal translations).
>
>A while ago we had a longer discussion about Esperanto names; in that
>discussion, it was questioned whether Esperanto could be in the name
>tag
>but nobody disputed that adding name:eo tags is ok, even though
>Esperanto is an invented (or "constructed") language.
>
>Yesterday someone added a few dozen Klingon names to countries in OSM.
>I
>have reverted that because of a copyright issue, but I think we also
>need to discuss which languages we want to accept for name:xx tags.
>
>In my opinion, a name:xx tag should only be added if you can
>demonstrate
>that people natively speaking the living language xx are actually using
>this name for this entity. I think we have a very unhealthy inflation
>of
>names in OSM that are added by "single-purpose mappers" - they come in,
>stick a name:my-favourite-language tag onto everything, and go away
>again. Nobody knows if these names are even correct, and nobody cares
>for their maintenance. The country North Macedonia changed its name
>almost one year ago, yet roughly half of its ~ 170 name tags are still
>what they were before this change. Nobody cares; these names suggest a
>data richness that is not backed up by an actual living community that
>cares for them.
>
>What are your opinions on which languages should be accepted in name
>tags? What do you think about
>
>* niche constructed languages (say, FredLang which has 2 words I
>invented just now)
>* popular constructed languages (Klingon, Elvish) - note place names in
>these languages will often be algorithmically derived from the English
>or local name
>* "serious" constructed languages (Esperanto)
>* languages that once existed but are not natively spoken any more
>(Roman)
>* languages that are natively spoken but their speakers do not have
>their own name for the entity in question (instead they use the same
>name the locals use, possibly transcribed into a different alphabet)
>* ...
>
>Or if you don't have the time to think about this in detail, just
>answer
>the question: tlhIngan Hol - Hlja' or ghobe'?
>
>Bye
>Frederik
>
>--
>Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
>E008°23'33"
>
>___
>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] Ponds are not observable on the ground

2020-03-19 Thread pangoSE

Hi

IMO pond should not be mapped because it is not observable on the 
ground. How do you determine if it is

"artificially created"/"man made"?
See:

A pond : a body of standing water, 
man-made in most cases, that is usually smaller than a lake.

https://wiki.openstreetmap.org/wiki/Tag:water%3Dpond

Lake: a body of relatively still fresh or salt water, localized in a 
basin that is surrounded by land. Artificially created lakes are tagged 
aswater =pond 
orwater 
=reservoir 
. 
Intermittent lakes (which disappear seasonally) should be tagged 
withintermittent 
=yes; salt lakes — 
withsalt 
=yes.https://wiki.openstreetmap.org/wiki/Tag:water%3Dlake 



As it stands right now in the wiki I suggest we either deprecate the tag 
completely or change the definition to something that is observable on 
the ground.


WDYT?

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


Re: [Tagging] change bicycle_parking=floor to surface

2020-02-03 Thread pangoSE


On 2020-02-03 08:41, Warin wrote:

On 3/2/20 6:32 pm, pang...@riseup.net wrote:




Then the issue of securing the bicycle?

bicycle_secure=lock,supervised,provided_lock,*

Could you elaborate what each of these mean?

I think bicycle_security is better



I would like to improve on this key name too ... but for the moment ..


values (subject to change, improvements and additions)


lock - a lock can be used to secure the bicycle to some fixed object 
-usually part of the holding mechanism.


supervised - a human watches over the area

provided_lock - a locking mechanism is provided, usually as part of 
the structure (shed/building etc)



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


Re: [Tagging] change bicycle_parking=floor to surface

2020-02-02 Thread pangose



>
>I don't think the solution of using surface will do.
>
>
>surface=paved says nothing about if the bicycle can be secured and what
>too.
>
>Nor does it say anything about how the bike is held.
>
>
>The bicycle_parking key is used for lots of things...
>
>buildings/sheds
>
>stands/racks
>
>A very poor key!
>
>
>I think the key should be replaced.

I agree. It is a bad idea to lump different concepts in one key.

>
>
>Buildings and sheds already have a key building=* so those values can
>be 
>depreciated.
>
>
>Stands/racks are all indications of how the bike is held while parked.
>
>bicycle_holding=stand/rack/bollard/post/* ?

I like this. 

>
>
>Then the issue of securing the bicycle?
>
>bicycle_secure=lock,supervised,provided_lock,*

Could you elaborate what each of these mean?

I think bicycle_security is better

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


Re: [Tagging] change bicycle_parking=floor to surface

2020-01-31 Thread pangose
I suggest we use additional tags to specify this more precisely.

I think the lack of supports should be tagged supports=no or bicycle_support=no.
Additionally lock_support=no or lock_stands=12. 
I'm not English so I don't know what would be the best word for these devices. 
In Danish they are probably called låsestolpe (lock pole) or låsebue (lock 
bow). In swedish I would call them låsbåge (lock bow) or perhaps låshjälp (lock 
help). 
 WDYT?

On January 31, 2020 10:04:02 AM GMT+01:00, Warin <61sundow...@gmail.com> wrote:
>Usually the bicycle rests on something. And if you going to leave it
>for 
>any time then locking it to some thing is a good idea.
>
>Floor may be a poor choice? Flat may be more descriptive? There is 
>nothing there for bicycles to lean on or be fastened to.
>
>(Yes I know some parts of the world bicycles normally come with stands 
>so they can be self suporting. But most bicycles hare have no stands.)
>
>
>On 31/1/20 5:50 pm, Thibault Molleman wrote:
>> I agree, was pretty confused when I saw that as well (after I had 
>> mapped a bunch of regular parkings and then did some bicycle ones)
>>
>> On Fri, Jan 31, 2020, 07:46 John Willis via Tagging 
>> mailto:tagging@openstreetmap.org>> wrote:
>>
>> https://wiki.openstreetmap.org/wiki/Key:bicycle_parking
>>
>> It lists “floor” as the value for a wide open outdoor space with
>> no stands or other affordances designated for parking bicycles.
>>
>> this seems weird to me. the ground / asphalt area next to a
>> supermarket is not a “floor”.
>>
>> we use “surface” in car parking lots, and there are many of other
>> types of indoor tags for tagging when a bike is in a building or
>> shed (similar to parking=multilevel).
>>
>> I think that the values be standardized and the wiki changed.
>>
>> there is 60 uses of (undocumented) =surface and ~260 uses of
>> (documented) =floor.
>>
>> we should standardize how we tag parking lots for any vehicle if
>> it is just a flat outdoor surface.
>>
>> Javbw
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] wikimedia_commons= and image= cleanup

2020-01-20 Thread pangoSE
I recently stumbled upon the tag wikimedia_commons see 
https://wiki.openstreetmap.org/wiki/Key:wikimedia_commons


Its definition is: "links to related Wikimedia Commons' media of the 
feature "


But, the only 2 examples contain no links (as in URL-links but instead 
file- and category names):


   wikimedia_commons=File:Bicycle crossing, Poland, Kraków, Josepha
   Conrada.JPG
   wikimedia_commons=Category:St Paul, Birmingham 

I see in the database that a lot of image= tags contains direct urls to 
Wikimedia Commons.


I suggest we discuss changing the definition to:"File- or category name 
to related Wikimedia Commons' media of the feature "


Furthermore I would like to hear if anyone have any problems with mass 
re-tagging of all commons URLs in image and wikimedia_commons tags to 
the above format. I will keep the changesets per country or smaller.


There are currently ~58062 image= tags containing "wikimedia": 
https://overpass-turbo.eu/s/PWp


There are currently 37 wikimedia_commons tags that start with "http". 
https://overpass-turbo.eu/s/PWq


See also the discussion of introducing these formatting restraints in 
the JOSM validator:

https://josm.openstreetmap.de/ticket/18579

Regards

pangoSE

PS: IMO it is a good idea to clean this up to get an idea of how many of 
our features have some kind (and what kind) of image linked to them. I 
would like to see statistics about this that also tells me whether the 
wikidata item of some OSM feature has an image P18 property.
PPS: I also suggested that we start rendering images on feature pages on 
openstreetmap.org, see 
https://github.com/openstreetmap/openstreetmap-website/issues/2515


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