from:"Tobias"

> I think it would help with community acceptance of a potentially large
> number of meta tags if you're somewhat frugal when it comes to adding
> new ones. [...]
> 
> In practice, this could mean ...
> 
> * ... not adding key:check_date when the key is first added, or when the
> value is changed as opposed to confirmed. (But update check_date tags
> that already exist on the object, of course.)
> * ... only using check_date where regular re-survey is plausible and
> useful. This ties in with your observations on re-check intervals. For
> example, there should be an opening_hours:check_date, but probably no
> building:levels:check_date.
I think the same. Basically, I only brought this up as a question
directed at the mailing list at all because in the linked github issue
[1] someone argued for always adding a check_date.

He makes some good points [1], also regarding the reliability of the
"timestamp" (last date changed) attribute of an element. But so far, the
voices here on the mailing list were mostly arguing for frugal use of
such meta-tags, so if no other voices that make a conclusive point for
being less frugal with such meta tags come up, I will take the measures
that you mentioned.

[1] https://github.com/westnordost/StreetComplete/issues/1836


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

> adding check timestamps as string tags for every single tag seems a lot of 
> bloat. One tag per object for me would be acceptable because it is indeed a 
> valuable information when something was last verified and no changes were 
> necessary.

Definitely it has the potential for that. And as Mateusz noted in
another branch, check_date tags themselves could become out-of-date if
successive editors do not update the tag together with the tag it refers to.

On the other hand, at least at this time I do not see the danger of this
[=every single tag is accompanied by a meta-tag] happening, neither
through individual usage of such meta tags nor by being set by
StreetComplete automatically because only a small fraction of tags are
likely to change in a timeframe of some years or below. In other words,
only for a small fraction of tags it makes sense to attach a check_date
to. A good example of things that change more frequently would be
smoothness or opening hours.

For example one surveyor may check on-site the smoothness and surface of
a road, but not check if the width is still correct because he doesn't
have anything with him to measure it. Also, he doesn't want to check if
the speed limit is still correct because that would require him to go up
the road at least until the next big intersection to find a speed limit
sign (or not). He may also not want to check whether all(?!) the bus
routes are still correct. Generally, some information tagged on an
element is also not verifiable on-site.
What this example should illustrate is that it is illusory to assume
that a mapper is both able and willing to check everything at once for a
certain element.

(Basically, StreetComplete is founded on the idea that surveyors don't
have to tag and check "everything" at once for any given element but
add/update the information bit by bit.)

---

On the topic of map maintenance, there is another information that is
currently missing (from the API) which would be helpful to maintain an
up-to-date map. It is a bit off topic because this topic is mostly about
StreetComplete / on-site map maintenance but I would like to still touch
on it shortly:

If the date + *source* of the last change made on (the geometry of an)
element was readily available, through the API or another meta-tag
(source=bing, anyone? ;-) ), this would help to identify areas that
should be updated because a new more current and/or detailed source
became available.
In Hamburg, we are lucky that the public authority provides us with
really detailed up-to-date satellite imagery that are far beyond bing
but there is no easy way to see which buildings and road geometries have
still been mapped on the basis of bing and which are already using the
better source.
So in a nutshell, the topic of how to find things based on old sources
is also very relevant for remote mappers.

Cheers
Tobias


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

Thanks!

> Secondly, I think having to evaluate the history is a challenge. But do
> you have to? 

No, I don't have to, thanks to such tags as check_date. But then again,
check_date, survey:date etc. only came to be invented because API
support was missing. It would be better to have somthing like that in
the API itself. I would welcome it.

> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).

Interesting approach, but what tag do you use for that? It sounds like
you use check_date for that, but check_date is documented as "The tag is
intended to document the last date, when an object as a whole or
specific tags of the object were checked and verified".

Cheers
Tobias


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

> It is completely possible to add this functionality to the API in a
> backwards compatible fashion, at the cost of a long per tag in the
> current table (assuming that we don't need the information for historic
> object versions, so at a reasonable cost space wise. There are a couple
> of semantic issues that need to be considered but definitely not rocket
> science. Where the big effort is likely adapting the internal tools
> (database dumps etc), cgi-map and in the end migrating the database.
> 
> If I can find some time over the next months I might prototype this, but
> if somebody can do it earlier pls be my guest.

I am happy that through this topic, the topic of API support for
recording and getting the last checked date gained traction (again).

We,... well, we probably could, but we shouldn't always rely on tags
like check_date etc.. As Mateusz Konieczny rightfully noted in another
branch, meta-tags as opposed to API support has the potential to become
out of date if successive editors forget to update the check_date tag
when they update the object or tag it is referring to.

So, all the more I say it is pretty awesome that you plan to conceive a
plan for this. Whatever comes out of it, in any case thank you for
taking an initiative, Simon!
Such a feature would also open up much more room for comprehensive
analyzing and QA tools focussed on map maintenance, a topic that is or
at least is becoming more and more important in my opinion. The
endorsements there were so far for the map maintenance in StreetComplete
indicate that the topic has become to take precedence in the minds of
many mappers, also of those usually not that involved in discussions in
the established channels.

Regarding changes to the API, it would then probably look like this?


  


Thinking a little bit about it, it would not be a 1:1 replacement of
some_tag:check_date=2019-09-04 because check_date is usually used for
when something has been checked on-site (survey). A timestamp on a tag
just records "a" change. That could have been a mechanical edit, like
for example the recent change of http:// urls to https:// urls where
possible. Though I guess this would be good enough, it may be worth a
thought whether to also include the source field of the linked changeset
in the tag xml.

I reckon a difficulty for implementing something like this would be the
issue of "touching" elements in order to update their timestamp. I think
this may be possible already with the current API, but what is really
missing would be the possibility to "touch" certain tags only - only the
tags that one checked but didn't change because there was no change
required.

Cheers
Tobias


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Tobias Knerr

Hi Tobias,

congratulations on your successful microgrant proposal! :) Maintenance
of existing data is a growing concern as OSM matures, so it's important
that we explore workflows for it.

On 23.07.20 18:06, Tobias Zwick wrote:
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?

I think it would help with community acceptance of a potentially large
number of meta tags if you're somewhat frugal when it comes to adding
new ones. There is some cost in mappers feeling obligated to update a
"companion tag" every time they update a regular tag, as well as in
visual clutter. These downsides will both be lessened with better
tooling, but as of today that isn't widely available yet.

In practice, this could mean ...

* ... not adding key:check_date when the key is first added, or when the
value is changed as opposed to confirmed. (But update check_date tags
that already exist on the object, of course.)
* ... only using check_date where regular re-survey is plausible and
useful. This ties in with your observations on re-check intervals. For
example, there should be an opening_hours:check_date, but probably no
building:levels:check_date.

I don't have any strong opinions on this, and you seem to have given
this a lot of thought already. Just adding my gut feeling to the wisdom
of the crowd here.

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Tobias Knerr

On 24.07.20 14:13, Peter Elderson wrote:
> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).

When it should be checked is opinion-based, though.

The date when you last checked a shop's opening hours it is a fact. But
opinions on how often one should revisit a shop to check the opening
hours again may vary a lot between mappers. So I think the former is
more suitable to be added to the OSM database.

There are some comparatively rare cases where you know in advance that
something will change (e.g. with construction that is scheduled to be
finished by a particular date), but imo that's more the domain of
opening_date or temporary tags.

> The routine is then, ask if check_date is absent OR when the current
> date is past the check_date.

I don't think this is a big benefit compared to "... OR when the current
date is X months past the check_date".

Also, I tend to prefer making software a little more complicated if it
lightens mappers' manual workload, so making at least some use of
history (e.g. so that no check_date needs to be set when a tag is first
added) seems reasonable to me.

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

[Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-23 Thread Tobias Zwick

and other shops open in
their place. Sometimes, it is also dependent on how it is currently
tagged whether it is likely that it changes within a number of years: If
a road already has a paved surface such as asphalt, it is less likely to
change than if it was just a compacted road. Same with facilities for
the blind or other things that "upgrade" infrastructure. The issue was
already d

Long story short, not all quests [2] would be eligible for re-survey and
those who are will have different intervals, partly also based on how
they are tagged now. I could use your input on how long these intervals
should be. The issue was already discussed in a GitHub ticket [3], but
now prepared a wiki page here in which further discussion could take place:

https://wiki.openstreetmap.org/wiki/User:Westnordost/Proposed_Resurvey_Intervals

-

So, that's all for now. Looking forward to read your constructive input!

Cheers
Tobias

[1]
https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Map_Maintenance_with_StreetComplete
[2] https://wiki.openstreetmap.org/wiki/StreetComplete/Quests
[3] https://github.com/westnordost/StreetComplete/issues/1766


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

Re: [Tagging] Automated edit of image tags suggestion

2020-06-28 Thread Tobias Knerr

On 27.06.20 11:18, Mateusz Konieczny via Tagging wrote:
> unlike other many image gathering sites, images there are
> likely to be reusable and with at least basic info being
> machine readable

None of this changes if the Commons image is linked from the image tag,
though. And in fact, I feel these traits (open license, machine-readable
metadata) should be turned into requirements for any image linked from
image=*.

> I would prefer to not mix it with image=*

Would you consider it desirable to have multiple images linked for the
same object (one per hosting platform)? If so, how should a data
consumer select one of them to display?

(Of course, this points at the fundamental issue that the selection of
an image for image=* and similar tags is inherently subjective, so
arguably a poor fit for OSM in the first place. But I guess that's one
of those "it's sufficiently useful/popular to make an exception from the
rules" scenarios.)

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

Re: [Tagging] Automated edit of image tags suggestion

2020-06-26 Thread Tobias Knerr

On 25.06.20 19:57, pangoSE wrote:
> 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

By your own numbers, there are over 8 image=* tags containing links
to Commons. That makes it the most popular key for images on Commons at
the moment. I don't think there's an established consensus for
deprecating this tagging style.

Because I haven't seen convincing arguments to replace image=* with one
key per hosting platform, I would instead favour doing the opposite:

* Deprecate wikimedia_commons=* (because it unhelpfully mixes links to
categories, images, and other media types – I agree that's an issue)
* Move category links to commons_category=*
* Move image links to image=*

In summary: We first need a consensus how links to Commons should be
tagged. Then we can use an automated edit to standardize the tagging.

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

Re: [Tagging] Name for new wiki pages about roles of members in route relations?

2020-06-26 Thread Tobias Knerr

On 25.06.20 19:46, Joseph Eisenberg wrote:
> Should individual pages for these roles be located at something like
> Role:main and Role:alternative?

So far, I believe roles are typically documented on the wiki page for
the relation type, rather than their own pages. I don't think there's an
established convention for wiki pages about individual roles yet.

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

Re: [Tagging] site relation definition

2020-06-17 Thread Tobias Knerr

On 17.06.20 12:27, Martin Koppenhoefer wrote:
> Can we remove the "man_made" requirement?

I'm ok with removing the requirement for objects to be man-made. I only
added this aspect back in because it had been silently lost during the
transition from the proposal page to the Relation:site page a day prior,
which I felt wasn't ok – this is a significant change that should be
done on its own, not as part of an unrelated rewrite where it's easily
missed. But I do not actually have any personal preference on this
matter one way or the other.

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

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Tobias Knerr

On 19.04.20 20:33, Paul Allen wrote:
> On Sun, 19 Apr 2020 at 19:29, Justin Tracey  <mailto:j3tra...@gmail.com>> wrote:
> 
> Another major exceptions where mapping as an internal node is
> better, IME, are notable (historical) buildings that currently house
> a business. More generally, if the tags of the building and business
> would conflict (e.g., name), then it makes sense to keep them as
> separate features.
> 
> 
> If the building's name is still used as the house name, that's not a
> problem. Otherwise old_name=* takes care of it.

Not in the general case (the name may continue to be in use, but not as
part of the address). And there are other tags which may warrant a
distinction between the building and the business, such as start_date.

I would say the cleanest way to solve this, where necessary, is by
creating separate features for the business and the building. Separate
features don't have to mean a node for the business, it can mean two
polygons.

Of course, that's more work than either of the two popular shortcuts, so
these still have their place. But polygons for businesses work no matter
whether there's multiple tenants or just one, and it even works for
indoor maps and other micromapping use cases.

Tobias

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

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Tobias Knerr

On 19.04.20 19:51, Shawn K. Quinn wrote:
> I have noticed an issue putting things like the address on large
> buildings. Sometimes software that generates routings (OsmAnd) doesn't
> handle it gracefully and routes you to the wrong place.

My preferred way to handle this is to tag a node of the building polygon
as entrance=yes or entrance=main to mark the location of the entrance.
This allows routing software to know where it should guide you.

(Whether any given routing software already supports this is a different
story, of course, but at over 2 million uses this is a thoroughly
established tagging practice.)

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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

2020-03-22 Thread Tobias Wrede


Am 20.03.2020 um 16:38 schrieb Paul Allen:
On Fri, 20 Mar 2020 at 13:50, Tobias Wrede <mailto:l...@tobias-wrede.de>> wrote:



I don't get your point here. Either someone wanted a package
delivered to his residence. In that case they gave the wrong
address information to the delivery guys.

Around here, the delivery guys get it wrong even when they have the full
address and no PO boxes involved.  The problem comes when the package
is addressed to the PO box and then the delivery guys do the "last mile"
getting it from the PO Box to the physical location, and get that wrong.

It seems I have a different understanding of the concept PO box. Around 
here if you have a PO box mail is delivered there and you go yourself 
pick it up, convenient for people who are rarely at home or get huge 
amounts of mail. In more rural areas I have seen letter boxes in one 
central point of a several km2 area or a box/bag at the next major road 
where mail is delivered to. Again you go there yourself to pick it up.


I must admit I fail to understand your kind of PO box. One delivery 
company delivers to the PO box (which address/location is known) and 
then some other guys pick the mail up there and take it to your home 
which they don't know anything about? Sounds strange to me.


Regardless of type of address shouldn't a shipment not always have the 
receiver's name on, too?




But as long as we tag phone numbers, websites, fax numbers etc. I
cannot see why we should discourage it, either.

If we're just mapping things that a paper map shows, we wouldn't map 
post/zip
codes either.  In some cases this other information, even PO Box, is 
useful,

so people WILL map it.  It's better we come up with a way of doing it than
have all those people come up with their own way.

I don't say we should do as a paper map creator does. I see why we map 
phone numbers: I am  in an unfamiliar area, look for a restaurant on the 
map, find one and then call ahead to see if they can accommodate me. If 
it's the day before I might look up the email address and drop them an 
email. But I see really rare cases where I would find a business on a 
map and then send a letter or parcel there. But as I said I'm fine with 
people tagging delivery a addresses deviating from physical addresses if 
they want to. I just should go in the contact name space in my opinion.


Tobias

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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

2020-03-20 Thread Tobias Wrede


Hi,

Am 20.03.2020 um 12:30 schrieb Paul Allen:


One of the parcel
delivery companies noted for delivering to the wrong
address (Hermes and DHL, I'm looking at you) has
dumped a package outside my door.  The address is
PO Box 123.  Which of the houses near me has that
mailing address?

I don't get your point here. Either someone wanted a package delivered 
to his residence. In that case they gave the wrong address information 
to the delivery guys. Should have given them a street/number or whatever 
is needed in your area to find the place. Or they wanted to have the 
package delivered to their PO Box, then the address information needs to 
be tagged to the post office where the PO Box is located and they need 
to chose a delivery company able to deliver to PO boxes.


(sorry for reordering)


So is PO box, etc. useful?  Yep.


I personally cannot really see a usecase. But as long as we tag phone 
numbers, websites, fax numbers etc. I cannot see why we should 
discourage it, either.


Tobias


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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

2020-03-19 Thread Tobias Wrede


Hi Warin.

Isn't the addr:* scheme used to describe the physical address of a 
location/building/amentiy/etc.?


PO Boxes, privat bags etc. are addresses where mail for someone residing 
at said location is delivered to.


As addr:* I would always put in what is needed to find the place as a 
visitor and that is a housenumbet and street, a house name or any other 
place name. And sometimes there might be nothing besides city or postcode.


Mail delivery address I would expect to find under the contact:* scheme 
if at all.


Tobias



While there are methods of entering street addresses there don't appear
to be any way to enter addresses that use Post Office Boxes and other
delivery types.

There is a proposal to may the existence of PO Boxes but no way to enter the
address data for those that use them.

As well as PO Boxes there exits several types of delivery methods in
Australia, below are listed all of the officially accepted types with their
officially accepted abbreviations.

Care of Post Office  CARE PO

Community Mail Agent.  CMA

Community Mail Bag CMB

Community Postal Agent  CPA

General Post Office Box GPO BOX

Locked Bag LOCKED BAG

Mail Service MS

Post Office Box PO BOX

Roadside Delivery  RSD

Roadside Mail Box/Bag  RMB

Roadside Mail Service  RMS

Private Bag  PRIVATE BAG

These all appear in the same placement of the addressed article. Perhaps
a new tag addr:delivery_type=* could be used?

Examples>

Mr Smith

PRIVATE BAG 32

Tennant Creek

Northern Territory  0862

addr:delivery_type=PRIVATE BAG 32

Mr Jones

GPO BOX 3

Sydney

NSW 2000

addr:delivery_type=GPO BOX 3

In these cases there is no house number, street. There are still
city/state/country and postal codes.

--

References?

https://en.wikipedia.org/wiki/Roadside_Mail_Box

https://www.staff.uwa.edu.au/facilities/mail/formats

https://meteor.aihw.gov.au/content/index.phtml/itemId/430096

https://www.barklyhomestead.com.au/  -'contact us' they use PMB for
Private Mail Bag.




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

Re: [Tagging] addresses on buildings

2020-01-05 Thread Tobias Knerr

On 05.01.20 19:22, Rob Savoye wrote:
>   I assume the right place for tags like 'addr:housenumber' &
> 'addr:street' are on the building way, and not a standalone node ?

If there is a 1:1 relationship between buildings and addresses, the
building way is the most sensible location for addr tags.

My subjective experience with unconnected address nodes is that I often
end up confused about which building outline(s) they were originally
meant to belong to.

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

Re: [Tagging] Discourage use of landuse=churchyard?

2019-12-23 Thread Tobias Zwick

It could be useful to check (at random) how the tag is currently used - as 
synonym for graveyard, or for religious or both, at times (-> tag is ambiguos) 
and put that info in the wiki as well.

If it's both as you suspect, it's a very good reason to point to the other tags 
instead.

Tobias 

Am 23. Dezember 2019 06:27:55 MEZ schrieb Joseph Eisenberg 
:
>The tag landuse=churchyard has been used several thousand times, but
>amenity=graveyard is over 10 times more common, and landuse=religious
>is 4 times more common.
>
>I would recommend discouraging use of this tag, because the wiki
>definition contradicts the plain-English meaning of churchyard, which
>is usually a graveyard (cemetry) or burial ground next to a church.
>
>The wiki page for landuse=churchyard claims "Used to map the area
>surrounding a christian church or chapel, particularly when this does
>not contain a graveyard" - this conflicts with the common English
>definition of the value.
>
>Cambridge Dictionary (UK):
>"an area of land around a church, where dead bodies are buried "
>
>Merriam-Webster (US):
>"a yard that belongs to a church and is often used as a burial ground."
>
>To avoid ambiguity, mappers can use the two well-accepted tags
>landuse=religious + religion=christian
>OR
>amenity=graveyard + religion=christian, depending on the situation.
>
>I would like to update the wiki page for landuse=churchyard to suggest
>not using the tag and changing to one of the other two tags +
>religion=christian instead.
>
>- Joseph Eisenberg
>
>___
>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] state of a proposal

2019-12-08 Thread Tobias Knerr

On 08.12.19 18:37, Catonano wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
> 
> What' s the state of this proposal ?

Well, I wouldn't hold my breath for a vote unless the author (or someone
who takes over the reins) reboots it, but this doesn't necessarily mean
the idea is abandoned – not all proposals are adopted through voting,
some are simply adopted by people starting to use it.

In the case of this particular proposal, some people have experimented
with using it for mapping and development (myself included, I described
some very preliminary results during my SotM talk last year). From that
development perspective, I still feel Marek's proposal is the most
promising take on the area:highway idea so far.

Note that, although someone has later written wiki pages for
Key:area:highway¹ and related tags, they describe the wiki editors' own
take on the key, rather than any of the formally proposed versions. As a
result, that content is different from and incompatible with the
proposal you linked to. Which is unfortunate, as it lacks the clear
definitions regarding separation of junction areas from the connecting
road areas etc., which I found helpful when experimenting with software
support for it. I'm concerned that, contrary to the proposal, it may not
be as well suited for use cases that go beyond uniformly "painting" an area.

Tobias

¹ https://wiki.openstreetmap.org/wiki/Key:area:highway

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

[Tagging] Tagging of bicycle anti-features

2019-10-28 Thread Tobias Zwick

We know how to tag certain bicycle features such as the "advanced stop line" [1]

It would be interesting to tag also anti-features. Most commonly, a cycleway 
that just ends  without merging it back onto the street. Currently, such a 
situation would be tagged the same as a track that is merged correctly onto the 
road. This situation is especially hindering if combined with cars parking 
closely to each other on the sides of the road.

How could this be tagged, for cycleways mapped on the road-way? Any suggestions 
how a tag for this could be named?

Greetings
Tobias

[1] https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl

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

Re: [Tagging] How to tag pedestrian lanes?

2019-10-21 Thread Tobias Knerr

On 21.10.19 12:12, Tobias Zwick wrote:
> Though, in regards of software support,  I  my earlier suggestion is better, 
> as no modification on existing software is necessary to understand that a 
> sidewalk without kerb is still for pedestrians and used the same as a 
> sidewalk, regardless of whether in (Oxford) English, one may or may not call 
> this thing "sidewalk".

Me too. As I see it, the core of the question comes down to whether the
OSM data model should put a pedestrian road section without a kerb in
the same general category as one with a kerb, or whether these should be
treated as separate concepts.

To me, it makes more sense to consider them as roughly the same thing
and model the distinction with an additional tag. For most use cases,
data users can likely handle them very similarly, even though I
acknowledge that there may be exceptions (such as Markus's example of
navigation for blind users).

In general, I don't think the definition of OSM keys should
automatically duplicate all nuances of the English dictionary,
especially ones that many non-native speakers will be unaware of.

Tobias

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

Re: [Tagging] How to tag pedestrian lanes?

2019-10-21 Thread Tobias Zwick

Shoulders are a common feature on many roads. And the tagging for this is 
already established. Maybe a different way to tag kerb-less sidewalks thus 
would then be 

shoulder=right
shoulder:right:access=foot
(or access no and ...:foot=designated?)
shoulder:right:width=1

Though, in regards of software support,  I  my earlier suggestion is better, as 
no modification on existing software is necessary to understand that a sidewalk 
without kerb is still for pedestrians and used the same as a sidewalk, 
regardless of whether in (Oxford) English, one may or may not call this thing 
"sidewalk".

 (Existing) software will treat shoulders primarily as a feature relevant for 
cars.

Tobias 

On October 21, 2019 9:40:03 AM GMT+02:00, Joseph Eisenberg 
 wrote:
>“Sidewalk” is North American English, but it’s used because the
>British term is “pavement”, which is confusing due to its dual
>meaning. As a North American I would expect it to be separated from
>the road by a curb (kerb) or a strip of grass.
>
>Oxford dictionaries definition, Pavement:
>"1. British A raised paved or asphalted path for pedestrians at the
>side of a road.
>- ‘he fell and hit his head on the pavement’
>- North American term:   sidewalk"
>https://www.lexico.com/en/definition/pavement
>
>Wikipedia claims:
>"... normally separated from the vehicular section by a curb. There
>may also be a median strip or road verge (a strip of vegetation..."
>https://en.wikipedia.org/wiki/Sidewalk
>
>These definitions fit my impression, as an American, that a "sidewalk"
>is a separate feature, not part of the same paved road surface as the
>main lanes of the highway.
>
>If there's just a painted line, we would normally call the space
>between the line and the edge of the asphalt "the shoulder" of the
>road in a rural area, or it can also be a "bike lane" if it's wide
>enough and there are certain markings.
>
>So I'm in favor of a new key like pedestrian_lane=right/left/both,
>rather than calling these a type of sidewalk
>
>- Joseph Eisenberg
>
>On Mon, Oct 21, 2019 at 3:51 PM Mateusz Konieczny
> wrote:
>>
>> 20 Oct 2019, 19:08 by selfishseaho...@gmail.com:
>>>
>>> On Sun, 20 Oct 2019 at 12:42, Tobias Zwick 
>wrote:
>>>>
>>>>
>>>> How about:
>>>>
>>>> sidewalk=right
>>>> sidewalk:right:kerb=no
>>>
>>>
>>> I dislike using these tags for pedestrian lanes for the following
>>> reasons (sorry if i repeat myself):
>>>
>>> * It doesn't make sense: if it doesn't have a kerb (or any other
>>> physical barrier) it isn't a sidewalk.
>>
>> I am curious about opinion of a native speaker
>> of British English.
>>
>> Are you maybe one?
>>
>> (Sorry for poor phrasing here,
>> I tried to make it less aggressive and failed)
>>>
>>> * Blind people are able to make out a sidewalk, but not a pedestrian
>lane.
>>
>> No one argues against tagging this info.
>> We only disagree how it should be tagged.
>>>
>>> * It's misleading: Data users may not know the tag
>>> sidewalk:right:kerb=no and thus may make wrong assumptions. For
>>> example, a navigation application may guide a pedestrian along a
>route
>>> with only pedestrian lanes instead of safer route with sidewalks.
>>
>> And with a new incompatible tag
>> routing software may guide along
>> road without even such lane, instead of
>> using route where at least pedestrian
>> lanes are present.
>>
>> In both cases routing software would
>> benefit from an upgrade.
>>>
>>>
>>> * pedestrian_lane= is simpler for mappers and data
>users.
>>
>> Depends on whatever you consider
>> it as a low quality sidewalk or
>> a separate feature.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>On 10/21/19, Martin Koppenhoefer  wrote:
>>
>>
>> sent from a phone
>>
>>> On 21. Oct 2019, at 08:51, Mateusz Konieczny
>
>>> wrote:
>>>
>>> I am curious about opinion of a native speaker
>>> of British English.
>>
>>
>> while I am not, I’m pretty sure the British term is pavement, not
>sidewalk
>> (for the kerb separated way, no idea about the marking separated way)
>>
>> We had deliberately chosen the word sidewalk for OpenStreetMap
>tagging
>> because of the ambiguity of ”pavement “
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] How to tag pedestrian lanes?

2019-10-20 Thread Tobias Zwick

I have seen this kind of sidewalk that is just a marked lane in Germany as 
well, usually as part of parking lots or larger company grounds.

How about:

sidewalk=right
sidewalk:right:kerb=no
sidewalk:right:surface=asphalt 

The most important thing is to tag whether there is a sidewalk or not. 
Regardless of whether it has a keen or not.

According to taginfo, sidewalk:right:kerb is already used a few times:
https://taginfo.openstreetmap.org/keys/sidewalk%3Aright%3Akerb#overview

Tobias 

On October 20, 2019 8:39:14 AM GMT+02:00, John Willis via Tagging 
 wrote:
>
>
>> On Oct 20, 2019, at 4:44 AM, Markus 
>wrote:
>> 
>> However i think that a sidewalk requires a physical separation to the
>> roadway
>
>
>I agree with you, and I tag all separated standard sidewalks as
>“sidewalks” (iD preset).
>
>however, there are a lot of narrow roads in Japan where the side of the
>road (between the white lane border line and the barrier wall along the
>road) is painted with a (thin) green stripe, and is considered a
>pedestrian path - usually around schools where children walk. The
>infrastructure in the area is very old, and they cannot widen the roads
>to be safer, so they paint the green line on to remind drivers to be
>safe and keep the pedestrians on one side. this is only around schools
>with narrow roads. New roads all have separated sidewalks, so no
>painted area is necessary. 
>
>I tag the green line as a highway=path and add a note=* to the way. 
>
>One example I have seen is much larger, and is a new “lane” created by
>converting a 2-way road to 1-way and giving the margin to pedestrians. 
>https://www.openstreetmap.org/way/667338935
><https://www.openstreetmap.org/way/667338935>.
>
>I do not think this is ideal, but it does properly map the marking and
>the routing that should be used for pedestrians. usually many roads in
>the area are narrow, and the designated way is best. 
>
>If some method is standardized, I will correct my mapping. 
>
>Note: these are not the blue cycle-lanes or cycle arrows in the road
>found on many narrow high traffic roads. 
>
>
>Javbw

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

Re: [Tagging] Guard booth building type

2019-10-07 Thread Tobias Zwick

How about porters_lodge, it's more general. It would cover the small building 
at the entrance of outdoor pools where you buy the tickets, same for other 
outdoor venues, the booth at the entrance of company/factory grounds, the guard 
booth at the entrance of gated communities etc.

Not sure if this word is common in English, I just looked up the translation of 
the German word for that.

Tobias 

On October 7, 2019 3:38:17 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Mo., 7. Okt. 2019 um 09:09 Uhr schrieb Mateusz Konieczny <
>matkoni...@tutanota.com>:
>
>> What would be the best tagging for guard booth minibuildings?
>>
>> I think that building=guard_booth would be the best one for objects
>> constructed
>> as guard booth.
>>
>
>
>I agree on the selection of building for the key, but the word "guard"
>may
>be too restrictive or misleading. There are many similar structures
>used
>for similar purposes, e.g. staffed by a "porter" or "gate keeper" or
>"janitor" (?) (someone who opens for example a lift gate), which would
>not
>be covered by this term. In my area there are also many similar
>structures
>placed mainly at big crossings, which are sometimes staffed by
>policemen
>(I'm not completely sure if they can control the traffic lights, but I
>guess not, because when chaotic situations occur they step out of the
>enclosement, put the whistle and in the mouth and regulate the traffic
>in
>person). The latter have a writing on them "municipal police", I would
>not
>consider them guard houses (although they look the same), these are
>typically airconditioned and will be locked when they leave.
>
>There's also a not so well known key (but still has more than 1000 uses
>as
>of now) to be added as a property to barriers:
>https://wiki.openstreetmap.org/wiki/Key:barrier:personnel
>(it is physically a different feature, but functionally very similar).
>
>And there's a proposal for extending surveillance which has a
>(functionally) similar property:
>https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_tags_for_Key:Surveillance#Guard
>
>Looking at taginfo, I also found security_guard=no/yes (no is by far
>more
>used)
>https://taginfo.openstreetmap.org/keys/security_guard
>
>and guarded=yes/nighttime/yes/daytime/...
>https://taginfo.openstreetmap.org/keys/guarded
>
>both of these are currently around 250 uses globally, and far from
>reaching
>"supervised=*" (200K uses)
>
>I wonder if the tag would also be suitable for "temporary" structures
>like
>tents, which may not always be as temporary as they look. For example
>there
>are such tents set up in Rome since the government decided to put armed
>forces in front of embassies, and this is a situation that goes on for
>many
>years, one example can be seen here in the background on the right:
>https://www.mapillary.com/app/?lat=41.87225687537841=12.496776313017108=17=2L3AoKjXelz-CEG5Z4JBQg=photo=0.5120040767123977=0.5725924352245725=0
>
>Cheers,
>Martin

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

Re: [Tagging] Feature Proposal - RFC - (Phone)

2019-10-05 Thread Tobias Knerr

On 28.09.19 10:31, Valor Naram wrote:
> now I'm ready to open a new proposal which you can see here
> https://wiki.openstreetmap.org/wiki/Proposed_features/Phone#Second_proposal_.28pending.29

I agree with the basic goal of ending the co-existence of phone and
contact:phone. I don't care that much about which one "wins", but having
multiple competing tagging styles around makes it just that little bit
harder for new mappers to learn the ropes (and for editor developers to
optimize usability). This particular co-existence has gone on for a
decade, and we should finally come to a decision.

That being said, I find the proposal a bit confusing as currently
written. It isn't clear to me if you are proposing any changes besides
deprecation of contact:phone, because there's a lot of text on that page
about country codes, the value syntax and such. Is this just
describing/affirming the status quo?

What adds to the confusion is that there are now multiple proposals on
the same wiki page, which is unexpected and messes with links and
categories. For example, that page is now in both the "rejected" and
"proposed" categories at the same time. Unless there's a strong reason
I'm missing, I suggest taking the conventional route of creating a new
page for your proposal.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

2019-10-01 Thread Tobias Zwick

Milestones are not necessarily located at the true distance of A to B. Not sure 
why this is the case, but I know that this is true for at least Thailand. 

On 01/10/2019 21:10, Paul Allen wrote:
> On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre  > wrote:
> 
> The addresses that utilize ‘Km’ as part of the actual address are always 
> related to a specific 'highway:milestone’ on that particular highway. For 
> instance, the address for the Hilton Guatemala Vista Real Hotel in Guatemala 
> - as it appears on their official website: 
> [https://www3.hilton.com/en/hotels/guatemala/hilton-guatemala-city-GUALLHH/index.html]
>  - is ‘Km. 9.5 CA-1 East Vista Real Complex, Guatemala City, 01015’. What 
> this means is the location is 500 meters from where the 'highway:milestone=9’ 
> on that particular ‘CA-1 East’ highway...
> 
> 
> I think we're close to hitting the record for how misleading a tag name can 
> be.
> 
> This is a proposal for a tag addr:milestone to allow us to specify a distance 
> in kilometres
> (not miles), of a house (not a milestone) and the nearest milestone isn't a 
> stone but a sign.
> If the locals call the road markers (marked in kilometres and which are not 
> stones)
> milestones then there is some slight justification for addr:milestone.  But 
> only slight,
> because the address doesn't give the nearest "milestone" but a distance along 
> a road.
> 
> If I understand you correctly, this is actually a distance along a particular 
> highway.  A distance
> from where, exactly?  A highway has two ends, and there may be a milestone 
> (that is neither
> a stone, nor marked in miles) 9km from each end.  I assume that since the 
> address
> is in Guatemala City, that would be what is used for addr:city; I also assume 
> that since
> the street is CA-1 East, that would be what is used for addr:street.  
> Therefore the only
> other thing required would be addr:distance to specify the distance from 
> addr:city
> along addr:street.
> 
> Unless the locals call road markers "milestones" and think of the "9.5km" in 
> terms of
> milestones, addr:milestone is a horrific misnomer and addr:distance better.
> 
> -- 
> Paul
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

[Tagging] Tagging meadow orchards

2019-09-18 Thread Tobias Zwick

Hey there

What is the best way to tag meadow orchards?

Most orchards are plantations with monocultures of one kind of tree, usually 
planted in rows and pruned to have a short trunk for easier picking.

There is another type of orchard, in German "Streuobstwiese", in English I 
think "meadow orchard" or "meadow with fruit trees". This orchard has many 
different types of fruit trees scattered all over the meadow. The trees are 
usually not pruned. The meadow serves multiple purposes: As a meadow and as an 
orchard.
(Nowadays) meadow orchards are less common, because they are less accessible to 
machines for hay harvest and less convenient to harvest the fruit.

Show the meadow orchard be 

a) an own tag, like landuse=meadow_orchard?

b) a subtag of landuse=orchard? Maybe orchard=meadow/plantation?

c) or should the "meadow orchard" be a landuse=meadow with every single fruit 
tree added separately? (Well, I suppose it could in any case, but that's quite 
a micromapping solution)

What do you think?

Tobias

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

Re: [Tagging] oneway street with two combined foot-cycle lanes

2019-09-18 Thread Tobias Zwick

Hi Volker 

The full tagging here would be:

oneway = yes 
oneway:bicycle = no  <- oneway not for bicyclists
sidewalk = both  <- there is a sidewalk on both sides
cycleway = track...which is also a cycleway and
cycleway:segregated = no...not segregated 

Because the unsegregated foot+cycleway is really slim, it'd be useful to also 
record the width of the sidewalk/cycleway in

cycleway:width = X

Greetings
Tobias


On 16/09/2019 21:29, Volker Schmidt wrote:
> How to tag a
> oneway street with a combined foot-cycle lanes on either side with oneway 
> restrictions for bicycles.
> To understand my description you need to look at the photo:
> 
> http://www.mapillary.com/map/im/ndVXZQlQxoTi_678lWXc9A/photo
> 
> 
> Thanks in advance
> 
> Volker
> 
> 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Virus-free. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> ___
> 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] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-08 Thread Tobias Knerr

On 08.09.19 18:26, Janko Mihelić wrote:
On Fri, Sep 6, 2019, 15:05 Janko Mihelić wrote:
> "*A Wikidata item cannot be connected to more than one OSM item*".
[...]
> If one wants to tag all route segments with a wikidata tag, I
> propose a general usage "*part:wikidata=**" which would be used when
> a single wikidata tag just isn't viable. Proposal wiki page here:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/part:wikidata

Seems reasonable enough to me. It upholds the (generally desirable) 1:1
relationship while offering a realistic solution for items where there
is no single OSM element representing the feature as a whole. Streets
are probably the most prominent example where this would be used.

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

Re: [Tagging] Feature Proposal - RFC - footway=indoor

2019-09-05 Thread Tobias Knerr

On 05.09.19 18:41, Jeremiah Rose wrote:
> Here's a proposal for marking indoor routes within a building mapped with 
> Simple Indoor Tagging. 

I can see some value in mapping routes through a room which is full of
obstacles, but I don't like the idea of using this where a routing graph
could be calculated from indoor=corridor/area/room polygons just fine.
While the slow progress of OSM-based routing engines in this regard is
regrettable, trading extra mapper hours for something that could be
realistically automated always seems wasteful to me.

Of course, if someone feels it's worth spending their time, that's
ultimately up to them and I'm not going to stop them. Even with that in
mind, though, there are some aspects of this proposal which I find
problematic as they might have collateral effects on many other data
consumers besides the ones it's designed to help:

* the lack of a clear statement that this tagging is to be used in
addition to the SIT tags on polygons and should not replace them
* use of highway=footway, rather than a new tag which would have no
effect data consumers which don't opt in
* sharing the same tag for both use cases (hints for routers without
good indoor support which should be ignored by more advanced routing
engines, versus routes which should always be preferred over
automatically derived routes).

Tobias

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

Re: [Tagging] tag templates in the wiki

2019-08-12 Thread Tobias Knerr

On 12.08.19 20:27, Martin Koppenhoefer wrote:
> AFAIK the template is not filled from wikidata.org but rather from a wikidata 
> installation on OpenStreetMap-Foundation servers (or for OpenStreetMap but on 
> another server), with information harvested in the osm wiki. It is a parallel 
> system to wikidata.org by wikimedia.(?)

Yes. The OSM "data items" use the same software as Wikidata, but it's an
entirely separate installation on wiki.openstreetmap.org. Technically,
it's just an add-on (extension) for the wiki software.

There *is* a Wikidata link on some key and tag pages, but that is simply
an outgoing external link which doesn't do anything magical and is
unrelated to the above.

Tobias

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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

2019-08-04 Thread Tobias Knerr

On 31.07.19 09:34, Warin wrote:
> There is no present default unit for power - see
> https://wiki.openstreetmap.org/wiki/Map_Features/Units#Default_units
> Adding a default would be good

Why would it be good to add a default value?

I believe explicit units are generally preferable because they avoid
ambiguity and misunderstandings. With other tags, values without an
explicit unit are already common in the database, so this usage needs to
be documented. But introducing a default for a tag that is generally
used with explicit units doesn't seem useful unless you *want* people to
start omitting the units and rely on the default.

> And the wiki could also state that a space is required between the
> numeric values and the units, if any.

The wiki mentions this as a general rule: "The following units can be
explicitly specified by adding them after the numeric value, separated
by a space". But I agree that this recommendation should also
be repeated on Key:* pages.

Tobias

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

Re: [Tagging] lanes = 0

2019-07-30 Thread Tobias Zwick

Also, the mention of that lanes key (should) only be used to denote the number 
of MARKED lanes was added in 2017 after a short discussion in the German forum 
about the same topic.

However, in this topic here on the ML, arguments were brought forth that made 
us get to a different conclusion (the one documented in the wiki, see recent 
change history) which is why I consider the decision reached in 2017 (to only 
include marked lanes) obsolete.

Tobias 

On July 30, 2019 1:19:32 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
>jerome.seigneu...@gmail.com>:
>
>> Please don't use lanes=0. That don't make sense!
>>
>
>
>if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>(as
>it is according to my understanding), then lanes=0 means no marked
>lanes.
>
>Cheers,
>Martin

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

Re: [Tagging] lanes = 0

2019-07-30 Thread Tobias Zwick

This topic again? We had this just a few weeks back and we actually reached to 
a conclusion that lanes=0 should NOT be used to denote that there are no marked 
lanes.

I believe I also documented that conclusion on the wiki, prompting here for 
review.

Tobias 

On July 30, 2019 1:19:32 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
>jerome.seigneu...@gmail.com>:
>
>> Please don't use lanes=0. That don't make sense!
>>
>
>
>if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>(as
>it is according to my understanding), then lanes=0 means no marked
>lanes.
>
>Cheers,
>Martin

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

2019-07-29 Thread Tobias Zwick

Sounds to me that those pages were incorrectly deleted. Only because someone 
can tag the abandonedness of a single tag of a feature, doesn't mean that the 
tag that applies to the whole feature is deprecated.

Actually, sine best practice is to map each feature as an own element (unless 
maybe both features encompass the whole element, i.e. a building), the plain 
non-namespace tag would probably be used in the vast majority of cases.

Even in cases where two or more features encompass the whole object, I can't 
really think of a use case where the namespacing made sense: For example a 
disused hotel in a stately building may be mapped on one element, but then, 
wouldn't the whole building not also be diused?

Tobias 

On July 29, 2019 8:23:42 AM GMT+02:00, Joseph Eisenberg 
 wrote:
>I was going to fix the status of abandoned=yes which is currently
>incorrectly listed as "obsolete". I thought it was probably
>deprecated, since the wiki page was deleted when Key:abandoned:*
>(namespaced) was made in 2015, but it's still used 40,000 times.
>
>The key disused (mainly disused=yes) is also used 60,000 times, even
>though the situation is the same: no wiki page, and the Key:disused:
>page suggests it is deprecated.
>
>Should these two be added to deprecated features, or should I recreate
>the deleted pages and change the status to something other than
>obsolete/deprecated?
>
>I see that there was just a mention added that landuse=quarry plus
>disused=yes might be more sensible than disused:landuse=quarry.
>
>Joseph
>
>___
>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] New page "Approval status" for "de facto", "in use", "approved" etc

2019-07-29 Thread Tobias Zwick

One or several wiki edits should stand at the end of every tagging discussion, 
to document the conclusions made.

Tobias 

On July 29, 2019 8:37:25 AM GMT+02:00, Warin <61sundow...@gmail.com> wrote:
>Err .. sent to tagging list, so response here. Not to worry, a little
>more chatter.
>(Should there be a wiki edit list? Or would 'we' all then have to join
>that well as the tagging list? Anyone not want to be part of the
>discussions on wiki edits possibly of relevance to tagging? )
>
>On 29/07/19 16:13, Joseph Eisenberg wrote:
>
>> (Not sent to tagging list)
>>
>> I think the idea was that a tree with a proper name is an important /
>> landmark tree?
>>
>> Perhaps you crazy Europeans name your special trees, eg King George's
>Oak?
>>
>> The other suggestion was to use "landmark=yes" but this key is also
>> not recommended. Someone needs to check how denotation=cluster is
>> actually used now days.
>
>Correct. I looked it up.  :)
>
>The key denotation is meant for special trees .. see
>https://wiki.openstreetmap.org/wiki/Key:denotation
>
>So I have changed the wiki again . to simply direct 'special tree'
>tagging to that page.
>https://wiki.openstreetmap.org/wiki/Tag:denotation%3Dcluster
>
>If people want to mention names .. the denotation page would be the
>better place for it.
>
>>
>> Joseph
>>
>> On 7/29/19, Warin <61sundow...@gmail.com> wrote:
>>> On 29/07/19 15:26, Joseph Eisenberg wrote:
>>>> I've edited the page:
>>>>
>>>> 1) I reworded some of the helpful changes that Mateusz Konieczny
>just
>>>> made, for better English style.
>>>>
>>>> 2) I've removed the implication that de facto / approved are
>>>> "recommended" and that "deprecated" / "discardable" etc. are "not
>>>> recommended".
>>>>
>>>> I also removed the suggestion that "de facto" tags are supported by
>>>> rendering / routing / editing software - while this is usually
>true,
>>>> it isn't what determines if a tag is given "de facto" status.
>>>>
>>>> 3) I removed "obsolete" status from the list with
>deprecated/discouraged.
>>>>
>>>> However, I now think I figured out what this status is supposed to
>>>> mean: it's supposed to be used for tags that were deprecated, but
>now
>>>> no longer even appear in the database, so the wiki page is only for
>>>> historical information.
>>>>
>>>> Do we really need a special status for this, or should is it ok if
>I
>>>> retag the 6 tags with this status to "deprecated"?
>>>>
>>>>
>https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22
>>>>
>>>> - Tag:abandoned=yes - recommended replacement abandoned:*=* - used
>34,000
>>>> times
>>>> - Tag:amenity=Kneippbecken - approved replacement is
>>>> amenity=kneipp_water_cure - used 0 times
>>>> - Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
>>>> Tag:man_made=power_wind - use  power=generator, generator:source=*
>>>> instead - used a couple of times only.
>>>> - Tag:denotation=cluster - for special trees. Recommend to use
>name=*
>>>> instead with natural=tree. Had been down to 0 uses at one point,
>but
>>>> now there are a few hundred?
>>> Gah! use name=* for something other than the name? No. Use the
>description
>>> key for that.
>>> Edited wiki to remove this suggestion.
>>>
>>>> So only amenity=Kneippbecken and man_made=power_* really fit the
>>>> "obsolete" status, though there are a number of tags currently with
>>>> "deprecated" that are also no longer found in the database.
>>>>
>>> Once something has been 'depreciated' but now has little to no
>presence then
>>> 'obsolete' is a good status for it.
>>>
>>>
>
>
>___
>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] [Indoor] is indoor=level walled ?

2019-07-26 Thread Tobias Knerr

On 23.07.19 13:42, PanierAvide wrote:
> So according to wiki, indoor=level doesn't involve having a implicit
> wall following the geometry. Is it something we agree on ?

indoor=level does not add an implicit wall.

However, building and building:part probably do have outer walls by
default, regardless of indoor=level or any other indoor mapping. There's
no solution for switching these walls off yet. We can't really assume
that the absence of an indoor=wall or indoor=room element means there's
no outer wall – fully indoor-mapped buildings are the exception, not the
rule.

Therefore, my suggestion would be to include a tag like wall=no on your
indoor=level polygon for these unwalled levels.

> According to wiki, indoor=wall can only be used on
> lines, so if I create a closed line, it should not render as an area
> (same behaviour as footways). Is it also something we agree on ?

Yes, a closed way with indoor=wall should be considered a line, not an area.

> Last question, if I want to create a wall as an area (imagine for
> example a wide pillar where no one can enter), should I just use
> indoor=wall + area=yes ?

Using area=yes makes sense here, yes.

Conceptually, I'm a bit uncomfortable with wall polygons because they
break the logic for doors and windows (which are nodes on the wall
ways). But for something completely solid like a pillar, this is
probably not going to cause problems.

Tobias

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

Re: [Tagging] shop=window(s) incorrectly deprecated in favor of craft=window_construction ?

2019-07-09 Thread Tobias Zwick

I always thought that there is no norm for standard sizes of windows, so every 
window is made to measure. (And in case of a larger construction project, then 
1000s of windows are made with the same measure)
Is this not true after all?

Tobias 

On July 9, 2019 4:54:59 PM GMT+02:00, ael via Tagging 
 wrote:
>On Tue, Jul 09, 2019 at 04:03:35PM +0200, Martin Koppenhoefer wrote:
>> 
>> like in only selling, not fitting/mounting them? Not offering to
>replace the glass, etc.? Can you go there to buy a window, and take it
>away, or will you order a window or maybe the whole facade which will
>then be produced and delivered to you? 
>> 
>> While a shop like this may exist, I must admit I have never seen it.
>Can you refer to a real example?
>
>Several in my area in UK. 
>
>ael
>
>
>___
>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] Removing an ATM

2019-07-09 Thread Tobias Knerr

On 09.07.19 15:04, MARLIN LUKE wrote:
> I have an ATM mapped in a street which does not exist anymore
> (apparently since 2014).

Historic features should not be mapped in OSM:

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_historic_events_and_historic_features

Therefore, an object which no longer exists can simply be deleted.
The editing history is still stored in our database even after an object
is deleted, so you don't need to worry about permanently losing data.

Tobias

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

Re: [Tagging] Maxweight wiki page changes

Ok, it seems that "unladen" is somewhat favoured here on the list because it is 
more precise, more common and conforms with the wording in the (UK) legislation.

I'll change the one mention in the wiki of "maxemptyweight" to 
"maxunladenweight".

Cheers
Tobias

On 06/07/2019 14:17, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 6. Jul 2019, at 12:53, Tobias Zwick  wrote:
>>
>> So "unladen" is the word used in UK legislation? Do you have a link?
>> Even if "unladen" is most commonly used in UK, I still find "empty" better 
>> because it is easier to understand what it means for non native speakers 
>> (simpler word).
> 
> 
> to me unladen seems more specific (I am not a native speaker of course), 
> empty could mean more things (seats removed? No gasoline in the tank?) 
> although I agree unladen also leaves it open whether it is with petrol or 
> without.
> 
> Ciao, 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] lit=yes/no threshold

> I am trying to make lit=yes/no definition more precise

I think that your suggestions would make the definition actually less precise 
because they add a fair level of subjectiveness: "necessary to bring your own 
light"

The least subjective definition is to map the physical presence of street 
lanterns on the way, not the light they emit. (This definition (though) would 
mean that a footway close to a lit street would be mapped as unlit as long as 
it does not have own lanterns.)

Tobias 

On July 6, 2019 12:24:18 PM GMT+02:00, Mateusz Konieczny 
 wrote:
>Some cases of lit=yes are clear (direct lighting of street/footway by
>lamps)
>
>Some cases of lit=no are clear (no lighting whatsoever)
>
>But in cities there is also often strong or weak ambient light, for
>example:
>
>- carriageway is directly lit with so powerful light that spillover
>light
>makes footway well lit - clearly lit=yes
>
>- spillover light is quite dim but enough to comfortably walk - also
>lit=yes
>
>- there is some ambient light, but not enough to walk without own
>source of light - lit=no
>
>- there is an ambient light, one can carefully walk, but only slowly,
>people with poor eyesight needs their own source of light - lit=no (?)
>
>Overall, I am considering adding to
>https://wiki.openstreetmap.org/wiki/Key:lit
><https://wiki.openstreetmap.org/wiki/Key:lit>
>recommendation to consider "is it necessary to bring your own light
>source to see it properly"
>as recommended threshold for footways/paths.
>
>Any problems with that or ideas for a better threshold between lit=yes
>and lit=no?
>
>disclaimer: I am trying to make lit=yes/no definition more precise as
>part of my grant
>https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849

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

Re: [Tagging] Maxweight wiki page changes

>Unladen weight is used in European countries to apply only to goods
>vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination.

Are you absolutely sure about this?

I am pretty sure myself that hgv are defined differently: as goods vehicles 
with a "gross vehicle weight rating" (gvwr), a.k.a. "gross vehicle mass" (gvm) 
or plainly said maximum laden weight above 3.5t

...  and also documented it this way on the Key:hgv page

Tobias

On July 6, 2019 1:38:34 PM GMT+02:00, Philip Barnes  
wrote:
>
>
>On Saturday, 6 July 2019, Warin wrote:
>> On 06/07/19 19:46, Colin Smale wrote:
>> >
>> > On 2019-07-06 10:48, Warin wrote:
>> >
>> >> On 06/07/19 18:16, Colin Smale wrote:
>> >>>
>> >>> On 2019-07-06 05:03, Warin wrote:
>> >>>
>> >>> On 05/07/19 19:33, Mateusz Konieczny wrote:
>> >>>
>> >>> 3 Jul 2019, 12:52 by o...@westnordost.de:
>> >>>
>> >>> 1.1 At the examples: for max empty weight, I propose
>the
>> >>> key maxemptyweight. It suggests itself.
>> >>>
>> >>> Added, with link back to this post
>> >>>
>> >>>
>> >>> Here that would be called "maximum Tare weight". In the UK? 
>> >>>
>> >>> Probably "maximum unladen weight." "Tare" does exist as a word,
>and 
>> >>> is frequently used in logistics (empty weight of containers etc)
>but 
>> >>> AFAIK not in the context of traffic regulations.
>> >>>
>> >>
>> >> Possibly not where you are.. but
>> >>
>> >> "registrable light motor vehicle means a motor vehicle that is 
>> >> registrable and has a tare mass that is not greater than 2,794 
>> >> kilograms."
>> >>
>> >> From
>https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
>> >>
>> >> And also in other traffic legislation in Australia...
>> >>
>> >> In the UK?
>> >>
>> >> "(h)the manner in which the tare weight of road vehicles, or of
>road 
>> >> vehicles of any particular class or description is to be
>determined. "
>> >> from https://www.legislation.gov.uk/ukpga/1985/72
>> >>
>> >>
>> > That is not a traffic regulation, that's about metrology. And by
>the 
>> > way, I am speaking as a Brit, so native speaker and somewhat 
>> > conversant with the laws and legal system. As I said, the word
>"tare" 
>> > does exist, and is used in certain specific contexts. But in 
>> > connection with road vehicles, everybody in the UK speaks of
>Unladen 
>> > Weight.
>> >
>> > https://www.gov.uk/vehicle-weights-explained
>> >
>> 
>> Ok.
>> Here trucks have small signs on there side, they state the tare
>weight 
>> and gvw. I think these are used to confirm the vehicle is not
>overloaded 
>> when inspected (we have both mobile and stationary testing).
>> Also tare is used to specify the maximum tare weight of a trailer
>that 
>> inexperienced drivers can use, and that is a road regulation. It may 
>> also be used for other things.
>> A fairly common term here.
>> 
>> -
>> Further nit picking..
>> The "Unladen weight" is usually done without fuel but in all other
>ways 
>> ready for the road -i.e. includes spare tyre/s, tools, battery,
>coolant, 
>> oil etc etc. ???
>> I think some manufactures sales brochures quote figures without some
>of 
>> these to make it appear that they have greater load carrying
>capabilities.
>> Again this may vary from place to place around the world.
>> 
>> 
>> I would be happy with "unladen weight" rather than "empty weight".
>> As for "maximum" .. I would use "limit" similar to the use of "speed 
>> limit". So it would become "unladen weight limit".
>> 
>> I don't think I have ever seen a sign limiting the unladen weight ..
>it 
>> is always a limit on the total weight that the structure is rated
>for.
>> So I don't think there is much point in discussing it? At least not
>from 
>> my limited knowledge.
>>
>Unladen weight is used in European countries to apply only to goods
>vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination.
>
>It has nothing to do with structures, it is to prevent heavy goods
>vehicles taking short cuts through residential areas.
>
>It only apples to goods vehicles, as you need buses to have access.
>
>Phil (trigpoint)

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

Re: [Tagging] Maxweight wiki page changes

So "unladen" is the word used in UK legislation? Do you have a link?
Even if "unladen" is most commonly used in UK, I still find "empty" better 
because it is easier to understand what it means for non native speakers 
(simpler word).

In the US, "empty" seems to be most commonly used, as it is also written on the 
signs while at the same time, the word is not exclusively known/used in the US 
- unlike mall, freeway, etc.

"maxbogieweight" caused confusion earlier and was misunderstood as synonymous 
to "maxaxleload" recently. "maxemptyweight" I think does not need documentation 
to clarify what it stands for, "maxunladenweight" might.

In the end, UK naming should usually win, but maybe "empty vehicle weight" does 
not sound so exotic to British ears?

Tobias

On July 6, 2019 11:46:33 AM GMT+02:00, Colin Smale  
wrote:
>On 2019-07-06 10:48, Warin wrote:
>
>> On 06/07/19 18:16, Colin Smale wrote: 
>> 
>> On 2019-07-06 05:03, Warin wrote: 
>> On 05/07/19 19:33, Mateusz Konieczny wrote: 
>> 3 Jul 2019, 12:52 by o...@westnordost.de: 
>> 1.1 At the examples: for max empty weight, I propose the key
>maxemptyweight. It suggests itself. 
>> Added, with link back to this post
>
>Here that would be called "maximum Tare weight". In the UK? 
>
>Probably "maximum unladen weight." "Tare" does exist as a word, and is
>frequently used in logistics (empty weight of containers etc) but AFAIK
>not in the context of traffic regulations. 
>Possibly not where you are.. but 
>
>"registrable light motor vehicle means a motor vehicle that is
>registrable and has a tare mass that is not greater than 2,794
>kilograms." 
>
>From  
>https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
>
>And also in other traffic legislation in Australia... 
>
>In the UK?
>
>"(h)the manner in which the tare weight of road vehicles, or of road
>vehicles of any particular class or description is to be determined. "
>from https://www.legislation.gov.uk/ukpga/1985/72 
>
>That is not a traffic regulation, that's about metrology. And by the
>way, I am speaking as a Brit, so native speaker and somewhat conversant
>with the laws and legal system. As I said, the word "tare" does exist,
>and is used in certain specific contexts. But in connection with road
>vehicles, everybody in the UK speaks of Unladen Weight. 
>
>https://www.gov.uk/vehicle-weights-explained

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

Re: [Tagging] one feature one element

2019-07-05 Thread Tobias Knerr

On 05.07.19 11:57, Mariusz wrote:
> On 05.07.2019 07:05, Joseph Eisenberg wrote:
>> [Examples of bad situations:] "An area object representing a
>> single-use building with a point object inside it. Move the tags to
>> the area object and delete the point."
> 
> This is common and widly accepted practice. Don't try to change mappers
> behaviour by editing wiki.

It's true that shop tags on building outlines are a common practice.
However, POI nodes inside buildings are likewise common. So I believe it
was a good idea for Joseph to remove this statement. It did present a
widely accepted practice as a "bad situation" in need of fixing, after all.

> It is fine to map multiple real objects with one osm element

It'd say it's ok as a shortcut during initial mapping, but it is far
from ideal. As soon as you want to add tags which only apply to one of
the features (you mentioned "start_date" or "operator" as two examples,
but of course there are more), using separate elements becomes necessary.

> Nothing new, this problem already existed with roads and bridges and was
> fixed by putting bridge name into bridge:name tag.

It wasn't properly fixed until the introduction of man_made=bridge –
that is, a separate OSM element for the bridge.

The bridge:name tag was only a band-aid for a single symptom of a deeper
issue. It did little to address the other symptoms, such as multiple
roads running across the same bridge, and tags other than name.

Tobias

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

Re: [Tagging] Maxweight wiki page changes

2019-07-03 Thread Tobias Zwick

Reviewed it. That is some impressive work, thank you for this!

A few remarks:

1. Maxweight

1.1 At the examples: for max empty weight, I propose the key maxemptyweight. It 
suggests itself.

1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. 
axles>=3 instead of axles=3

2. Maxweightrating:

2.1 At the examples, Poland: This sign is actually an access restriction for 
all HGVs: hgv=no. By definition in EU laws and most other countries, a heavy 
goods vehicle is a goods vehicle with a GVWR of 3.5t and above. See the wiki 
page for Key:hgv for a longer explanation.

3. Maxaxleload mentions that weight in USA must always be given in short tons 
while the maxweight article also mentions pounds. Same with the article about 
maxbogieweight.

4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.

Tobias 

On July 3, 2019 9:43:12 AM GMT+01:00, Mateusz Konieczny 
 wrote:
>There were recently significant changes at OSM Wiki page about
>maxweight tag
>and related tags. Review is welcomed.
>
>See
>https://wiki.openstreetmap.org/wiki/Key:maxweight
><https://wiki.openstreetmap.org/wiki/Key:maxweight> - major changes
>included fixing mistakes
>in examples, adding additional examples, reformatting, documenting how
>object without max weight
>sign may be tagged
>
>https://wiki.openstreetmap.org/wiki/Key:maxweightrating
><https://wiki.openstreetmap.org/wiki/Key:maxweightrating> - page itself
>is quite new. Recent changes
>included reformatting and new examples
>
>https://wiki.openstreetmap.org/wiki/Key:maxaxleload
><https://wiki.openstreetmap.org/wiki/Key:maxaxleload> - smaller
>changes, but for completeness:
>fixing mistake and additional examples
>
>Again, review is welcomed!

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

Re: [Tagging] New sections added to "Good Practice" page?

2019-07-01 Thread Tobias Zwick

Maybe mobile-but-usually-stationary (or with a fixed schedule) amenities and 
shops could get an extra tag to denote that property. For example mobile=yes or 
something.
POIs with this tag set could be resurveyed more often than others.

Tobias 

On July 1, 2019 11:15:32 AM GMT+01:00, Paul Allen  wrote:
>On Mon, 1 Jul 2019 at 09:49, Martin Koppenhoefer
>
>wrote:
>
>>
>> For example there are boats used as restaurants, they could move, but
>they
>> don’t (in some instances at least).
>
>
>Got one of those near me.  I've mapped it.
>
>
>> Or mobile fruit or ice cream vendors, which may be there only during
>the
>> daytime, but will be there every day.
>>
>
>Or mobile food vendors who have a fixed spot but take the trailer home
>at
>night.  Got two of those
>near me, and I've mapped them.  There used to be three, but one of them
>upgraded from a
>mobile vehicle to a building.
>
>Or a mobile butcher serving small communities and visits each community
>on
>a fixed day of the
>week at a fixed time.  Got one of those near me, but I've not mapped it
>(can't find his schedule).
>
>Or mobile banks.  Got several of those near me.  They're in each
>village
>for a couple of hours one
>day a week.
>
>Or mobile libraries.  Similar deal to the mobile banks.
>
>Or a ticket office for boat trips.  It's a trailer in a fixed location
>and
>remains there overnight but
>is only present during the tourist season.  Got one of those near me.
>
>Generally it doesn’t seem a good idea to add stuff to the „good
>practice“
>> page at this stage, without consulting with the wider community
>before.
>>
>
>I've altered the "good practice" page to state that it should not be
>changed without consulting
>the wider community.  Joking.

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

Re: [Tagging] paid ferry - fee or toll tag

2019-06-22 Thread Tobias Zwick

Colin Smale, this is a very wise thing to say. I think this is often a missing 
element in tagging discussions.

Is there a tagging suggestion guidelines page on the wiki? If yes, this is 
definitely one point that should be added. And if not,  maybe we (people on the 
mailing list) should create one: Not too set up rules, but just to get everyone 
on the same page regarding what a good tag design is.

On June 22, 2019 11:03:31 AM GMT+02:00, Colin Smale  
wrote:
>On 2019-06-22 10:38, bkil wrote:
>
>> If we step back a bit from our dictionaries, fee=* as a concept is
>> isomorphic to toll=* (and fare) in this context.
>
>Only insofar as they indicate that the user has to pay. "Toll" has a
>distinct meaning, in the UK at least, that it is (and needs to be)
>sanctioned by law. 
>
>> As all of them could
>> be understood by native speakers and fee=* covers a more general
>> category, it is clearly the better choice. If we consider our data
>> users, non-native speakers and learning curve, the less terms we use
>> in our vocabulary, the better.
>
>"As simple as possible, but not simpler". Attributed to Albert
>Einstein,
>and a philosophy I wholeheartedly embrace. If it is required to be able
>to make the distinction between a charge levied based on a legal
>sanction, and a charge simply levied by the owner because they feel
>like
>it, then the subtle difference between "toll" and the other words is
>significant. If we all agree that the distinction is not to be
>represented in OSM, then this discussion is moot - call it something
>neutral like payment, fee, charge, whatever. This process is called
>data
>modelling; the modelling aspect comes from the fact that you have to
>make compromises, and you have to choose which compromises to make
>according to what is important to you. Otherwise you are just
>replicating reality at full scale, which defeats the point of
>modelling.
>
>
>As this is OSM, it only takes one person to want to make this
>distinction to unchain interminable discussions... 
>
>> On Thu, Jun 20, 2019 at 11:20 AM Paul Allen 
>wrote:
>> On Thu, 20 Jun 2019 at 01:33, Warin <61sundow...@gmail.com> wrote:
>> The Oxford Dictionary says
>> 
>> Toll : A charge payable to use a bridge or road.
>> 
>> Yep.  Also, in the UK, carries legal implications.  Legislation is
>required to require tolls on a
>> public highway.
>> 
>> Fee : A payment made to a professional person or to a professional or
>public body in exchange for advice or services.
>> 
>> That's how I'd use it.  Of course, ferries provide a ferry service,
>so fee could be used.  But I'd go
>> with something else: fare.  We don't talk of rail tolls or rail fees,
>we talk of rail fares.  We don't talk
>> of air tolls or air fees, we talk of air fares.  From OED online:
>"The money paid for a journey on
>> public transport."
>> 
>> --
>> Paul
>> 
>> ___
>> 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] lanes = 0

2019-06-16 Thread Tobias Zwick

Okay, to wrap this up, I added this title in the wiki and referenced back to 
this discussion, advising to not use lanes=0/1.5/none to signify no lane 
markings but instead use something like lane_markings=no.

https://wiki.openstreetmap.org/wiki/Key:lanes#No_lane_markings

---

Additionally, I noted that after a similar discussion about lanes=1.5 in the 
German forum in 2017, the wiki page was changed to stress that the lanes-key is 
for *marked* traffic lanes. The change was announced on the Talk page and the 
German forum discussion linked there.

I did not change the formulation back but only added the outcome of this 
discussion to that topic on the Talk page because I do not feel legitimated to 
do that as the 2017 wiki change was also done only after discussion in the 
community, same as now:
https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#No_centerline_-_one_or_two_lanes.3F

[1] https://forum.openstreetmap.org/viewtopic.php?pid=627975#p627975

On 15/06/2019 18:55, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 15. Jun 2019, at 01:10, Joseph Eisenberg  
>> wrote:
>>
>> This requirement is fine for Europe, but the presence of lane markings
>> is not reliable in all of the world.
>>
>> In developing countries, such as here in Indonesia, the presence of
>> painted lane markings is inconsistent. Often cheap pain is used
>> instead of more durable thermoplastic, so the markings only last a
>> year. After that the road still functions the same, even though the
>> markings are no longer visible.
>>
>> There are also sections of primary or trunk road that are at least 6
>> or 7 meters wide and freshly painted, but have not yet been marked and
>> may not be for a number of years. I tag these as lanes=2 because the
>> road is clearly wide enough for two lanes.
>>
>> And here in town the main road was recently marked with 2 lanes in
>> each direction, but before it already functioned as 4 lanes because
>> the width was sufficient.
>>
>> While tagging the width is useful, I believe tagging the presence of
>> "de facto" lanes is reasonable in developing countries and places
>> where painted lane markings are not frequently used.
> 
> 
> 
> This description is a perfect fit for the situation in central Italy as well, 
> not having marked lanes can happen on 2+2 roads for years and for many 
> kilometers. Often there are lane markings for some part of the road while 
> they are missing on others. Generally they are aiming at having lanes, but it 
> isn’t pursued with high priority ;-)
> I can understand the argument that lanes have to be painted in order to be 
> there, but it isn’t the reality I am observing.
> 
> We shouldn’t dismiss lane_markings=no as it can solve both cases: no lanes 
> marked but lanes=n is set, and no lanes tag set (confirmation the tag wasn’t 
> forgotten).
> 
> 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] shop=cannabis including medical cannabis

2019-06-14 Thread Tobias Zwick

Wouldn't medical cannabis be sold in pharmacies?

On 14/06/2019 18:26, Jmapb wrote:
> An accepted answer to a recent question on help.openstreetmap.org (
> https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> ) suggested expanding the definition of shop=cannabis to include
> dispensaries for medical cannabis.
> 
> This makes sense to me, and the original discussion (
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> ) doesn't really give any clear reason for excluding medical cannabis
> shops. (In fact, the subtags cannabis:medical and cannabis:recreational
> are proposed and not disputed.)
> 
> I'm inclined to go ahead and edit the shop=cannabis wiki page (also take
> out some of the verbiage... the history in Colorado is interesting but
> not really relevant to the map) but I'd first like to fish for
> objections. (Agreement also welcome!)
> 
> Thanks, Jason
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] lanes = 0

2019-06-14 Thread Tobias Zwick via Tagging

Ok so to recap. All fairly weak reasons (except 2) here, but let's find the 
best tag:

1. Allroads did not favour nolanes=yes because it is a double negative

2. lanes=no is not so good because there are people who estimate the lanes 
value if no markings are present (see ael's message). Adding "no" as a possible 
value that is to be applied when no visual markings are present would make a 
portion of the currently tagged lanes-tags wrong and thus would be a 
redefinition of the lanes key.

3. lane_marking=no has of the proposed tags the least semantic similarity to 
the lanes tag but on the other hand is used a few times already and is safe for 
the "_" instead of the ":" what Warin suggested

4. lanes:mark...=no would maybe imply that lanes=X must be tagged as well?

On 13/06/2019 15:15, Tobias Zwick wrote:
>> I think a tag to say "lane:marking=no" could be better for that situation???
> 
> 1. or lanes:marked=no? (mark_ed_ instead of mark_ing_)
> 
> Would be (more) consistent with the naming of opening_hours:signed, 
> collection_times:signed, (1k-2k usages each)
> 
> 2. or nolanes=yes?
> 
> Would be consistent with noname=yes, noaddress=yes, ...
> 
> 3. or lane_marking=no? I found this on taginfo, it has 90 usages. Personally, 
> I like either 1 or 2 better though.
> 
> Point 1 and your (Warin's) suggestion have the advantage that it semantically 
> refers to the lanes-key. Though on the other hand, would that imply that 
> lanes=X should always be tagged if lanes:marked=no is tagged?
> 
> 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] lanes = 0

2019-06-13 Thread Tobias Zwick

> I think a tag to say "lane:marking=no" could be better for that situation???

1. or lanes:marked=no? (mark_ed_ instead of mark_ing_)

Would be (more) consistent with the naming of opening_hours:signed, 
collection_times:signed, (1k-2k usages each)

2. or nolanes=yes?

Would be consistent with noname=yes, noaddress=yes, ...

3. or lane_marking=no? I found this on taginfo, it has 90 usages. Personally, I 
like either 1 or 2 better though.

Point 1 and your (Warin's) suggestion have the advantage that it semantically 
refers to the lanes-key. Though on the other hand, would that imply that 
lanes=X should always be tagged if lanes:marked=no is tagged?

Cheers
Tobias

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

Re: [Tagging] lanes = 0

2019-06-13 Thread Tobias Zwick

> Here, legally, if there are no lane makings then it is considered to have one
> lane in either direction.

I am kind of a fan of lanes=0, denoting that there are no marked lanes. Here is
why:

a. if a road with no lane marking is tagged as lanes=2, this situation cannot
be distinguished from a road with 2 lanes
b. if a road with no lane marking is tagged as lanes=1, this situation cannot
be distinguished from a road with 1 marked lane (a oneway road?)

So, in both these cases, the tagging is not explicit.

But it is important to be able to make the distinction. Some reasons:

1. Verifiability: Clearly, "on the ground", a road with 2 lanes looks different
from a road with no lanes. A famous example for even a very broad road that has
no lanes is Place Charles-de-Gaulle in Paris [1]

2. Legal implications: As far as I know, there are legal implications for roads
with no lanes. Depends on the country of course, two examples that come to my
mind:

2.1 In Germany, (afaik) it has implications when passing obstacles. If there
are marked lanes, you can only cross into the other lane when it is free, while
if there are no marked lanes, whoever reaches the obstacle first may pass
first, independent on whose "side" it is

2.2 In China, the default speed limit if nothing is signed in towns is 50
km/h but on urban roads without a center line, it's 30 km/h [2]

3. Fuzzy/Implicit implications: Software may want to treat roads with unmarked
lanes differently from ones that are marked. A few examples:

3.1 StreetComplete may want to ask surveyors to measure a road width in
meters only for unmarked roads because they are likely very thin and the
traffic throughput is not clear through the lane count

3.2 router software may want to slightly prefer roads with lanes>=2 over
unmarked roads and/or calculate a virtual lane count from the given width, if
any - especially if the maxspeed-tag is missing

3.3 map rendering software may want to render roads as they appear in
reality. F4Map already does this rudimentary [3]

---

Now, my argumentation is in favour of making a distinction between unmarked and
marked but not explicitly for lanes=0. I wouldn't mind or even slightly favor a
tag like nolanes=yes or similar - this would be even more explicit. But since
this does not exist (yet), lanes=0 would do as well in my opinion because it
also reads as "zero (=no) lanes".

Cheers
Tobias

[1] see
https://www.google.de/maps/@48.8734657,2.2942766,3a,75y,117.5h,85.1t/data=!3m7!1e1!3m5!1s4ofE9aRZMKKfWiiB2SiOrQ!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3D4ofE9aRZMKKfWiiB2SiOrQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D166.38968%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192

[2] see https://wiki.openstreetmap.org/wiki/Default_speed_limits

[3] see https://demo.f4map.com/#lat=53.5832254=9.9338489=19

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

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

2019-05-24 Thread Tobias Zwick

Sorry in hindsight I should have left out the last paragraph, please ignore it. 
I would rather not discuss concrete suggestions for software but collect ideas 
for certain modes of communications that may make constructive communication 
happen more.

On 25/05/2019 02:28, Tobias Zwick wrote:
> 
> 1. Thesis: Mailing lists (and to a lesser degree, classical forums) promote a 
> culture of dissent. This is because if people just agree, they tend towards 
> not answering at all on these mediums because they do not want to litter the 
> conversation when they don't have something own to say. So, as someone posing 
> a topic that does not develop into a long thread (like this one), you never 
> know if it was due to that nobody is interested, or if everyone is like "ok 
> sounds good".
> Now, what we actually want to achieve when starting a discussion on the 
> mailing list or forums to get so some kind of result with which all or most 
> people are actually fine with, to a consent. 
> 
> 1.1 A Solution: In real life, if you agree but have nothing more to say, you 
> simply show that by nodding or clapping. While, if you don't, you voice this 
> and state your reasons. So, I think simply a  "sounds good" button, aka  
> "like" (facebook) or  "clap" (medium.com) will make a big difference. (Did 
> you know that a "thanks" button was introduced in our wiki recently? Use it!) 
> This will make it much easier also for people who usually just lurk on the 
> mailing list and don't feel they want to actively participate in the 
> discussion to give the people who write some feedback.
> 
> 2. Get more "normies" on board. I think it can only be good for the overall 
> communication culture to get more people on board. 
> 
> 2.1 Linked from the main page. Was already mentioned before in this thread 
> somewhere - the communication medium should be linked directly from the 
> openstreetmap.org start page to get more people on board. See for example 
> https://kotlinlang.org/community/ on how it could look like
> 
> 2.2. OAuth. Users should simply be able to use their openstreetmap login, no 
> further registration required.
> 
> 3. Moderation and Edits.
> 
> 3.1 Edit: Every now and then, people derail verbally, it happens. We are all 
> humans. So, to be able to edit your post after you realized that you 
> shouldn't have said something inflammatory, abusive or stupid, is important.
> 
> 3.2 Report: And sometimes, a person will just not cool down and fail to see 
> that he is being abusive, then this needs to be moderated in order to keep 
> the discussion factual. An abusive comment on the mailing list will stay 
> forever, while one on a well moderated medium will only be seen by those that 
> see it before it is reported. Having an abusive comment just stay there, even 
> if it is rebuked, broadcasts a nasty odor and poisons the discussion. This is 
> the "toxicity" that pops up time and again here. Don't underestimate 
> emotions. Just remember how this discussion here started ( 
> https://lists.openstreetmap.org/pipermail/tagging/2019-May/045501.html ). So, 
> my conclusion, *good* moderation is most important really.
> 
> 3.3 Moderation: Sometimes discussions go off topic or branch off. Especially 
> if using a threaded forum or a mailing list. Then, it should be possible to 
> put those branches into own threads.
> 
> 3.x All three are not possible on a mailing list, but at least in the forum.
> 
> All those points I mentioned are nothing new or outrageous. Any modern 
> conversation software will have all of this.
> 
> For example F-Droid (Android OpenSource Software Repository) and Kotlin 
> (modern programming language) both use Discourse. Could this be an option to 
> replace both the mailing lists and the forums? https://www.discourse.org/
> 
> I am talking about replace here, because one part of the problem is, is that 
> the community is so scattered ("filter bubbles").
> On 25/05/2019 01:43, Tobias Zwick wrote:
>>> Sometimes, it goes the other way - the good way. There's consensus, or if 
>>> disagreement, the different options are offered constructively. You can see 
>>> that happen pretty often. How do we make that happen more?
>>
>> The discussion pretty quickly drifted from considering technical solutions 
>> to behaviors, toxicity, cultural differences etc. etc., I have read this a 
>> thousand times. I don't see how this brings us forward.
>>
>> But I was waiting for a cue like this. Thank you for that, Nick. Let's be 
>> positive, and talk about ideas.
>> We can't change the people, but we can change the communication medium which 
>> can

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

2019-05-24 Thread Tobias Zwick

1. Thesis: Mailing lists (and to a lesser degree, classical forums) promote a 
culture of dissent. This is because if people just agree, they tend towards not 
answering at all on these mediums because they do not want to litter the 
conversation when they don't have something own to say. So, as someone posing a 
topic that does not develop into a long thread (like this one), you never know 
if it was due to that nobody is interested, or if everyone is like "ok sounds 
good".
Now, what we actually want to achieve when starting a discussion on the mailing 
list or forums to get so some kind of result with which all or most people are 
actually fine with, to a consent. 

1.1 A Solution: In real life, if you agree but have nothing more to say, you 
simply show that by nodding or clapping. While, if you don't, you voice this 
and state your reasons. So, I think simply a  "sounds good" button, aka  
"like" (facebook) or  "clap" (medium.com) will make a big difference. (Did you 
know that a "thanks" button was introduced in our wiki recently? Use it!) This 
will make it much easier also for people who usually just lurk on the mailing 
list and don't feel they want to actively participate in the discussion to give 
the people who write some feedback.

2. Get more "normies" on board. I think it can only be good for the overall 
communication culture to get more people on board. 

2.1 Linked from the main page. Was already mentioned before in this thread 
somewhere - the communication medium should be linked directly from the 
openstreetmap.org start page to get more people on board. See for example 
https://kotlinlang.org/community/ on how it could look like

2.2. OAuth. Users should simply be able to use their openstreetmap login, no 
further registration required.

3. Moderation and Edits.

3.1 Edit: Every now and then, people derail verbally, it happens. We are all 
humans. So, to be able to edit your post after you realized that you shouldn't 
have said something inflammatory, abusive or stupid, is important.

3.2 Report: And sometimes, a person will just not cool down and fail to see 
that he is being abusive, then this needs to be moderated in order to keep the 
discussion factual. An abusive comment on the mailing list will stay forever, 
while one on a well moderated medium will only be seen by those that see it 
before it is reported. Having an abusive comment just stay there, even if it is 
rebuked, broadcasts a nasty odor and poisons the discussion. This is the 
"toxicity" that pops up time and again here. Don't underestimate emotions. Just 
remember how this discussion here started ( 
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045501.html ). So, 
my conclusion, *good* moderation is most important really.

3.3 Moderation: Sometimes discussions go off topic or branch off. Especially if 
using a threaded forum or a mailing list. Then, it should be possible to put 
those branches into own threads.

3.x All three are not possible on a mailing list, but at least in the forum.

All those points I mentioned are nothing new or outrageous. Any modern 
conversation software will have all of this.

For example F-Droid (Android OpenSource Software Repository) and Kotlin (modern 
programming language) both use Discourse. Could this be an option to replace 
both the mailing lists and the forums? https://www.discourse.org/

I am talking about replace here, because one part of the problem is, is that 
the community is so scattered ("filter bubbles").
On 25/05/2019 01:43, Tobias Zwick wrote:
>> Sometimes, it goes the other way - the good way. There's consensus, or if 
>> disagreement, the different options are offered constructively. You can see 
>> that happen pretty often. How do we make that happen more?
> 
> The discussion pretty quickly drifted from considering technical solutions to 
> behaviors, toxicity, cultural differences etc. etc., I have read this a 
> thousand times. I don't see how this brings us forward.
> 
> But I was waiting for a cue like this. Thank you for that, Nick. Let's be 
> positive, and talk about ideas.
> We can't change the people, but we can change the communication medium which 
> can have a very big effect.
> 
> I would like to brainstorm what features of a desired communication medium 
> would have a positive impact on the discussion culture, and also on the 
> ability of us, to find something like a consensus.
> 
> Please, everyone, feel invited in this branch of this thread to give some 
> input. I have some ideas myself so I will start with that, but in the next 
> message. :-)
> 
> Tobias
> 
> On 25/05/2019 00:47, Nick Bolten wrote:
>>> What I'd suggest is that (much as I suggested before) everyone tries to 
>>> understand how points of view can be misunderstood and how conversation

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

2019-05-24 Thread Tobias Zwick

> Sometimes, it goes the other way - the good way. There's consensus, or if 
> disagreement, the different options are offered constructively. You can see 
> that happen pretty often. How do we make that happen more?

The discussion pretty quickly drifted from considering technical solutions to 
behaviors, toxicity, cultural differences etc. etc., I have read this a 
thousand times. I don't see how this brings us forward.

But I was waiting for a cue like this. Thank you for that, Nick. Let's be 
positive, and talk about ideas.
We can't change the people, but we can change the communication medium which 
can have a very big effect.

I would like to brainstorm what features of a desired communication medium 
would have a positive impact on the discussion culture, and also on the ability 
of us, to find something like a consensus.

Please, everyone, feel invited in this branch of this thread to give some 
input. I have some ideas myself so I will start with that, but in the next 
message. :-)

Tobias

On 25/05/2019 00:47, Nick Bolten wrote:
>> What I'd suggest is that (much as I suggested before) everyone tries to 
>> understand how points of view can be misunderstood and how conversations 
> can go downhill, when each side believes that there is malice on the other.  
> This thread is actually a pretty good example of it ...
> 
> Yes, of course. It's important to ask questions and assume the best, when 
> possible.
> 
> Sometimes, the insults are as subtle as a sledgehammer. It's not 
> miscommunication, it's a free-for-all, and it turns away new users. I've seen 
> it happen in real time.
> 
>> The initial "OSM needs an alternative for community tagging discussions" 
>> message in the other thread said a number of things that surely were not 
>> intended as 
> personal attacks but were directed at a place with which people felt a sense 
> of community, and therefore _were_ interpreted as direct personal attacks.  
> I'd suggest everyone asks themselves "If I write this, how will it be 
> interpreted?  How will it make other people feel?".
> 
> This point is well-taken. I should have contextualized my points so that it 
> was clear that I'm objecting to a particular atmosphere and want it to 
> improve. I do believe there are fundamental problems with the mailing list 
> format that contribute to that atmosphere.
> 
>> The next thing that I'd suggest is when someone has said something out of 
>> order (or that seems at first glance to be out of order) to wait a 
> bit before replying.  An initial retort will be be unlikely to contain the 
> clearest thought out response.  If you've managed to get into an argument 
> with someone and the other person behaves in a particularly childish way, you 
> can rely on someone else to tell them that what they are saying is silly (as 
> happened in this thread when Clifford Snow intervened).
> 
> Of course, but this won't help new users asking questions. They will still 
> have a negative experience. This is still (in theory) a volunteer-driven 
> effort, so that really matters. They can (and do) just leave. You can see 
> that the main dev of the most popular editor has already given up on these 
> lists for very similar reasons. That's why this is relevant: that's a 
> surprisingly reasonable response, so how can we fix it? How can we interface 
> properly and decrease alienation?
> 
> Finally, while it is surely helpful when certain behavior is called out as 
> unacceptable, and it's appreciated, it doesn't happen nearly often enough to 
> establish a minimum sense of decorum.
> 
>> Finally, (and this is one for British politicians as well) if it feels like 
>> everyone's ganging up on you and no-one seems to agree, stop, take 
> a step back and try and draw a thread between what "everyone" seems to be 
> saying.
> 
> Oh, I think "ganging up" is fine so long as it's civil. That would be 
> something like consensus - sounds great! 
> 
> I may not be making my point about disagreement clear. I love disagreement: 
> it's healthy, it's productive, there's no other way to get consensus. New 
> users should be met with it, when appropriate. We should all have robust 
> discussions about differing views to establish the meaning of tags.
> 
> However, it's hard to see how "establish the meaning of tags" is served when 
> there are 3, 4, 5, 6, etc absolutist, often insulting, yet also incompatible, 
> opinions offered. That forces the visitor into this position: ignore at least 
> N - 1 of those people and either give up or plod along hoping that those 
> positions can be, in some way, taken back. I'm not simply talking about 
> proposals: if you ask, "how do I tag this?" and are in that s

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

These are some valid points, and I also have some input to that, but are you 
sure you want to discuss this on the tagging ML? The talk ML might be a better 
spot for this, this topic has already strayed quite far from the original 
topic. (And maybe start the topic on a more positive prospect instead of with a 
rant ;-)

Tobias

On 23/05/2019 21:58, Nick Bolten wrote:
>> Yes, it would be great. There is plenty of negative emotion on both sides 
>> and it would be great to reverse this (for example title that I used was 
>> frankly stupid what I realized after sending the message).
> 
> OSM needs an alternative for community tagging discussions outside of these 
> mailing lists. Ones that people will actually use and that have a reasonable, 
> community-oriented code of conduct. I have talked to 10X more people about my 
> `crossing` proposals outside of this mailing list (in-person, personal 
> emails, slack, etc.) and the differences could not be more stark:
> 
> # My experiences with OSMers in other contexts:
> - Very friendly, all focused on making maps better, highly motivated to 
> donate their time to help others via the map.
> - Disagreements are pleasant. Both sides acknowledge the other point of view 
> and usually come around to a compromise.
> - There is interest in knowing more: lots of questions back and forth.
> - Objections are qualified and polite.
> - 10s-100s of people giving feedback on a single idea.
> 
> # My experience with this mailing list:
> - Quick to exasperate.
> - You will be assumed to be coming to the table in bad faith.
> - You will probably be insulted at some point, potentially sworn at.
> - The same 8 or so people respond to posts out of a community of tens of 
> thousands of people, companies, non-profits, etc.
> - The odd situation of absolute certainty in completely incompatible opinions 
> from those that do respond.
> - Difficult for people to discover. How do we know that the opinions shared 
> here are in any way representative of the community, given that so few 
> discover + participate in it?
> - Difficult to filter for relevance. Have to set up email filters and/or 
> specialized search queries.
> - Zero real synchronization with OSM editors, the only way people add data to 
> the map. Blame doled out everywhere, but very little in the way of 
> collaboration, no real venue for doing so (see previous bullet points).
> 
> Focusing on the idea of being an "arbiter", does that sound like a good way 
> to figure out which tags are good/acceptable?
> 
> When I was mentoring a group of students a few years ago, several were 
> offended by the condescending and insulting responses they received on this 
> mailing list, all because they suggested making a coherent way of combining 
> existing tags into a pedestrian schema and doing a carefully-vetted import. 
> The import was so carefully-vetted that we later realized it wasn't even 
> really an import, but this didn't stop there being several insulting 
> accusations from several long-term OSMers on these lists. Those students were 
> motivated by helping other people and spent literal months attempting to 
> gather enough information from underspecified tagging standards and would 
> have been put off the community entirely if it weren't for the project's 
> momentum and much more productive and friendly interactions with local 
> OSMers. I think it's probably a good thing that it's so hard to even know 
> that there is a mailing list, as users have a negative experience.
> 
> To boot, there are technical problems solved by virtually every other 
> messaging system:
> - Difficult to discover.
> - Virtually impossible for new users to join recent discussions - they need 
> to have subscribed to the list first.
> - Discovering old discussions is difficult, requires some nerdy prowess.
> - Terrible security practices. Passwords sent in plain text over email. No 
> encryption. I was almost put off the mailing list entirely when I saw this. 
> Completely unacceptable.
> 
> Gripes aside, I have a suggestion: move these discussions to a real forum 
> system, properly organized around regional/topic-specific/tagging 
> discussions. It could be a revamped https://forum.openstreetmap.org/ or 
> something fancier and slack-like (like riot chat). Have actual moderators and 
> code of conduct. The current mode of communication is systematically flawed.
> 
> On Thu, May 23, 2019 at 12:06 PM Mateusz Konieczny  <mailto:matkoni...@tutanota.com>> wrote:
> 
> 23 May 2019, 18:32 by o...@westnordost.de <mailto:o...@westnordost.de>:
> 
> reverse this development.
> 
> Yes, it would be great. There is plenty of negative emotion on both sides 
> and it

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

I'd say so. 

On 23/05/2019 19:03, Nick Bolten wrote:
> So would it be fair to say that a linear *=platform implies foot=yes and can 
> be tagged with reasonable tags for a footway such as width, incline, surface, 
> tactile paving, etc?
> 
> On Thu, May 23, 2019, 9:46 AM Tobias Zwick  <mailto:o...@westnordost.de>> wrote:
> 
> "Redundant" is perhaps not the best way to describe the problem. I'd go 
> about this like this:
> 
> A "highway=footway" is a footway, a "public_transport=platform" is a bus 
> stop (platform). These are simply two different things. They *share* certain 
> properties, for example, they are accessible both by pedestrians, but that 
> does not make a bus stop platform a footway.
> Giving an extreme example: Paved brownfields and parking lots are not 
> footways. But following the argument of the iD developers, they probably 
> should.
> 
> Tobias
> 
> On 23/05/2019 18:26, Nick Bolten wrote:
> > I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.
> >
> > Taking a step back, can anyone name an instance where a linear transit 
> platform is not a footway?
> >
> > On Thu, May 23, 2019, 12:49 AM Markus  <mailto:selfishseaho...@gmail.com> <mailto:selfishseaho...@gmail.com 
> <mailto:selfishseaho...@gmail.com>>> wrote:
> >
> >     I agree that adding highway=footway to platforms is not only
> >     redundant, but (as pointed out by Michael) is bad because platforms
> >     often have different access restrictions than highway=footway. iD's
> >     validation rule should be removed.
> >
> >     Regards
> >
> >     Markus
> >
> >     ___
> >     Tagging mailing list
> >     Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> 
> <mailto:Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>>
> >     https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

"Redundant" is perhaps not the best way to describe the problem. I'd go about 
this like this:

A "highway=footway" is a footway, a "public_transport=platform" is a bus stop 
(platform). These are simply two different things. They *share* certain 
properties, for example, they are accessible both by pedestrians, but that does 
not make a bus stop platform a footway.
Giving an extreme example: Paved brownfields and parking lots are not footways. 
But following the argument of the iD developers, they probably should.

Tobias

On 23/05/2019 18:26, Nick Bolten wrote:
> I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.
> 
> Taking a step back, can anyone name an instance where a linear transit 
> platform is not a footway?
> 
> On Thu, May 23, 2019, 12:49 AM Markus  <mailto:selfishseaho...@gmail.com>> wrote:
> 
> I agree that adding highway=footway to platforms is not only
> redundant, but (as pointed out by Michael) is bad because platforms
> often have different access restrictions than highway=footway. iD's
> validation rule should be removed.
> 
> Regards
> 
> Markus
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

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

Re: [Tagging] ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

I simply have the feeling that we are heading straight for an escalation course 
here. I already see it looming that some day the plug might be pulled on iD 
(being hosted on openstreetmap.org) and I really really don't want this to 
happen, lest even to think about it makes me sick.

Undoubtedly, the developers behavior is not helping there. I have the 
impression that they have almost given up on the OSM community. But this 
doesn't come out of nowhere.  I think it is important to understand their side 
of the story if we were to reverse this development.

I had to rewrite this last paragraph several times, but, well, I hope this does 
not come across the wrong way...
it can certainly not continue like this, so ... why not interview him, honestly 
and with open outcome, how should the collaboration and communication in OSM 
happen in the future from his point of view? Would he rather feel relieved or 
rather feel betrayed if the gatekeeping (~deployment) is done by other people? 
Does he really feel alienated (because I assumed it) from the community and if 
yes, why? And most importantly, what would it take to reverse this? 

Tobias

On 23/05/2019 17:15, Mateusz Konieczny wrote:
> Though repeated attempts by @bhousel and @quincylvania to declare themselves 
> as
> final arbiters of OSM tagging and dismissing everybody else is certainly not 
> helping.
> 
> That is really not going to work, and it is a pity because plenty of work 
> done of him is really great
> but it is tainted by ignoring arguments of critics. No one is right all the 
> time.
> 
> To directly quote part of
> https://github.com/openstreetmap/iD/issues/6409#issuecomment-495231649
> 
> "Some things that don't really factor at all into our decision:
> 
>     how long a tag with implicit semantics has been in use
>     how many softwares (renderers / routers or whatever) already support the 
> implicit rule
>     how frequently the tag is used
>     what a handful of people on a mostly dormant mailing list think
>     what one person has written on the osm wiki
>     how many downvotes you encourage people to put on our issue list
>     what they are saying about us in the weekly osm tabloid"
> 
> So someone is dismissing what everybody else thinks and at the same time 
> expects everybody
> to accept his own opinions?
> 
> Some ideas from tagging mailing list and OSM wiki (even after limiting to 
> popular ones
> or "approved") are pointless/harmful but that is not a valid reason to simply 
> ignore all of them.
> 
> 23 May 2019, 10:16 by o...@westnordost.de:
> 
> I like your wording. It is a burden. He also takes all the complaints for 
> bugs and when iD steps on someone's shoes. This is a very stressful position 
> to be in.
> 
> 
> 
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations