Re: [Tagging] Kerbs

[Matej Lieskovský]

How does this work with roads raised to the level of the sidewalk?

On 31 Dec 2017 19:43, "Selfish Seahorse"  wrote:

On 29 December 2017 at 00:32, Nick Bolten  wrote:
> That's a really great example of how it may make sense to separate out the
> idea of a 'curb ramp' from the curb interface. I might have to steal it!

Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height?

@Warin: Thanks for the links.

Wishing everyone a happy new year!

___
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] emergency bays - which side?

[Matej Lieskovský]

I guess the problem is that for a bidirectional road it is not clear, which
direction is oncoming traffic.

On 31 Dec 2017 22:16, "Graeme Fitzpatrick"  wrote:

>
> On 31 December 2017 at 19:47, Volker Schmidt  wrote:
>
> How do I indicate the side of the road the EB is serving in the case of a
>> bidirectional road.
>>
>
> Wouldn't an emergency bay always be on the side of the road away from
> oncoming traffic eg drive on left, bay is at left side of road, drive on
> right = bay on right?
>
> Thanks
>
> Graeme
>
>
> ___
> 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] Variable position

[Matej Lieskovský]

I suspect I did not describe the situation well enough. The park is 2.4 ha.
There are some fixed benches in some parts of the park and cca 50 moveable
ones in the main area, where there are no fixed benches. The moveable
benches line three paths in somewhat irregular intervals of about 10m. I
suspect the benches are moved by a few meters by the gardeners in order to
spread out the wear on the grass underneath them and make it easier to mow
the grass. While the benches line both sides of about 250m of paths, they
don't move too far from their original positions.

The current situation is that the benches are mapped according to some
ortho. While inaccurate, I still think that describes the current situation
better than some area.

On 30 Dec 2017 09:31, "Martin Koppenhoefer" <dieterdre...@gmail.com> wrote:

>
>
> sent from a phone
>
> > On 28. Dec 2017, at 14:06, Matej Lieskovský <lieskovsky.ma...@gmail.com>
> wrote:
> >
> > The benches are there, quite probably within 10m of their location in
> the map. While this is abysmal accuracy, it is not entirely wrong.
>
>
> 10m absolute location accuracy for a spot within a much bigger area isn’t
> abysmal at all, it is typical.
> Some hundred meters would be abysmal accuracy.
>
> Still, with several benches and this location precision it could mean a
> heart shaped arrangement of benches, a star, a circle, an S, etc. and
> therefore quite misleading overall
>
>
> 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] Variable position

[Matej Lieskovský]

Hello,

is there a way to map objects, whose position changes slightly?
Example:
I know a park that has a few dozen benches. They are there practically
all-year-round, but their position changes every now and then. A fixme
would imply that the problem can be fixed (which does not seem practical),
leaving them out completely is less than ideal and leaving them as nodes
gives a false sense of precision, which is not perfect either. Is there a
way of saying "there are benches somewhere around here"?

Merry X-mas,

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

Re: [Tagging] Kerbs

[Matej Lieskovský]

I'd say the first picture is a flush kerb followed by a ramp.

On 7 January 2018 at 20:12, Selfish Seahorse 
wrote:

> Not, it's not ideal, you are right. It's just an idea to create some
> order, because the current kerb scheme isn't ideal either. Even if
> only three out of four wheelchair users were satisfied with
> `mountable`, `semi-mountable` and `non-mountable` this would be a step
> forward, in my opinion. Besides, I didn't think of these values to be
> a replacement for kerb:shape, but an addition.
>
> However, if we want to make the current scheme more usable, it is
> necessary to also specify the angle of inclination for sloped kerbs
> (and maybe kerb ramps too). Compare the following two kerbs, which
> have the same shape, but a different level of accessibility:
>
> 
> 
>
> Regards
>
> On 7 January 2018 at 19:15, Nick Bolten  wrote:
> >> * `mountable`: mountable for wheelchairs and vehicles (...)
> >
> > While this may seem easier to tag on a first pass, it's not ideal, as
> it's
> > making a broad-brush executive decision about accessibility on behalf of
> > others. I'm also not sure how it's different from wheelchair=yes/no
> combined
> > with access=* tags. Describing neutral on-the-ground conditions is
> better,
> > both for accessibility and general use by all mappers/data consumers.
> > Examples:
> >
> > - Athletic manual wheelchair users can mount moderate-height raised
> curbs.
> > - Adventurous manual wheelchair users may want to use driveways as well,
> > where it may not be intuitive to always map accessibility, but does make
> > sense for a curb interface.
> > - Most electric wheelchairs can't handle moderate-height raised curbs.
> > - Souped-up electric wheelchairs can handle even fairly high curbs.
> > - People with impaired stability may strongly prefer moderate-height
> curbs,
> > but don't care about the shape.
> > - A white cane user may want to know whether to expect a certain curb
> shape
> > for navigational purposes.
> > - What about `semi-mountable version 2`, curbs mountable by souped-up
> > electric wheelchairs but not other vehicles?
> >
> > These users can all be accommodated by curb shape and height tags, and
> most
> > can be mostly-accommodated just with curb shape. This is also one of the
> > reasons very few wheelchair maps exist: if you state 'here's the places
> all
> > wheelchairs can go' you'll get a lot of very different complaints, both
> > about not having enough possible routes ('I don't care about curb ramps,
> > just tell me where big displacements and driveways are') and also too
> many
> > ('I can't handle 8 cm displacements, and this rolled curb kept me from
> > making my trip').
> >
> > Best,
> >
> > Nick
> >
> > On Sun, Jan 7, 2018 at 9:15 AM Selfish Seahorse <
> selfishseaho...@gmail.com>
> > wrote:
> >>
> >> On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote:
> >> > kerb:shape=* would be better as it suggests what is to be tagged.
> >>
> >> Thus, `kerb=*` values could be replaced with:
> >>
> >> * `mountable`: mountable for wheelchairs and vehicles
> >> * `semi-mountable`: not mountable for wheelchairs but mountable for
> >> vehicles
> >> * `non-mountable`: neither mountable for wheelchairs nor vehicles
> >>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] cycleway:both=no in StreetComplete

[Matej Lieskovský]

Ok. Look.
I wrote a long rant about how cycleway=no is a horrible idea and then I
deleted it.
I have no idea where you map, but here, >90% of roads never even heard
about cycleways. For us here, it makes sense to consider cycleway=no to be
implicit, as the information that someone surveyed it is not worth the
extra tags. Your location might differ, and in that case I envy you.
Now, you want to have cycleway=no explicitly tagged. I want to stop the
spam of cycleway=no tags. Someone in the Netherlands might want to assume
cycleway=both as the default. (The cycleway tag is just an example here.)
Could we perhaps agree that we need a way to list assumed and implied
values on a smaller than global level? And ideally have a formal way of
writing that down?
You set cycleway=no as assumed for your region. I set cycleway=no as
implied for mine. Our fictional friend from the cyclist's heaven-on-earth
sets cycleway=both as assumed or even implied. Changes to this policy will
move to local talks. Data consumers will have a list of rules to apply
instead of having to guess. Everyone will live happily for ever after.
Sounds good?

On 5 January 2018 at 11:04, Fernando Trebien <fernando.treb...@gmail.com>
wrote:

> Well, by not adding tags with assumed default values, we simply cannot
> distinguish them from the situation where they have not been verified.
>
> For instance, some mappers don't care about cycleways but still map
> streets. How can somebody that cares about cycleways know that they
> should verify the presence of cycleways on ways surveyed by others?
> Now suppose this mapper then surveys a big area and finds no cycleways
> there. How can this person tell others they don't need to repeat the
> survey? By adding cycleway=no to all the streets this becomes obvious.
> By not adding them, there will be further unnecessary surveys. Mapper
> effort that could have been invested in other more valuable activities
> is therefore wasted.
>
> On Fri, Jan 5, 2018 at 2:15 AM, Matej Lieskovský
> <lieskovsky.ma...@gmail.com> wrote:
> > I agree that this deserves a separate topic, but I want to respond to
> some
> > points you made.
> >
> > I don't like the highway_defaults idea. Default values should be assumed
> > whenever they are not explicitly given. I don't think that a tag that
> states
> > "most of those are probably going to be correct" is useful. In general,
> we
> > don't even have a way of saying "everything is OK here". Feel free to
> > disagree, but I think that the most reasonable path is relying on users
> > reporting discrepancies. I'd simply apply the defaults everywhere and, if
> > someone notices an error, it will get fixed. Tagging "this default is
> > correct" will lead to the same DB bloat as not having defaults.
> >
> > Using the most common value as default has a major problem:
> > the most common values are oneway=yes, tunnel=yes, ford=yes.
> > I think that exceptions to the rule should be tagged, leaving the
> majority
> > up for defaults.
> >
> > I'm strongly in favour of dealing with the defaults on a local basis -
> > defining defaults for elements in a given administrative area would be a
> > good beginning, but letting us draw the extent of individual defaults
> would
> > (for example) give us an elegant way of tagging maxspeed=30 zones for
> free.
> >
> > I think that data consumers would appreciate a system, that would fill in
> > the relevant defaults for them. I'm not entirely sure how to make it,
> but it
> > sounds doable. Worst case scenario would be a special server providing an
> > "extended" database.
> >
> > As a final remark, I'd consider a two-level system:
> > Assumed values are reasonable defaults, but should be confirmed by an
> > explicit tag when possible.
> > Implied values are those that are almost certainly correct and only
> > exceptions should be tagged.
> >
> > Assumed values are good for the consumers and can be implemented
> reasonably
> > safely. This will provide an opportunity to test some of the relevant
> > systems.
> > Implied values are what will make the database cleaner, but are more
> > debatable. I think they are going to be OK, provided that we are careful
> > about adding new ones.
> >
> > On 5 January 2018 at 00:09, Fernando Trebien <fernando.treb...@gmail.com
> >
> > wrote:
> >>
> >> On Thu, Jan 4, 2018 at 9:57 AM, Matej Lieskovský
> >> <lieskovsky.ma...@gmail.com> wrote:
> >> > 1) If we try to add every possible tag to every element, the DB will
> be
> >> > immense and the OWG will try to kill us. Imagine eve

Re: [Tagging] default value

[Matej Lieskovský]

1) If we can agree that this is needed, I believe it can be built. We would
need to first agree on a notation (wiki is not machine readable), but the
rest should be fine. Worst case scenario is having a system that takes a
planet.osm file and "expands" it, resulting in a separate server with
periodically recalculated data. Could you link the proposal please?

2) I'd be perfectly happy to not know the difference until someone notices
the map being wrong, but feel free to go ahead with local solutions. Unlike
the defaults system, survey:date is unlikely to actually need a global
consensus.

On 5 January 2018 at 13:44, marc marc <marc_marc_...@hotmail.com> wrote:

> Le 05. 01. 18 à 13:23, Matej Lieskovský a écrit :
> > Could we perhaps agree that we need a way to list assumed and implied
> > values on a smaller than global level?
>
> there are two problems:
>
> 1) a list of some local default exists (e. g. speed values according to
> the type of road per country). the problem is the lack of a schema to
> assign these values indicated on the wiki to the osm data.
> every router for exemple have his own not-opensource-opendata schema to
> retrive those value.
> there is an unsuccessful default value proposal but unfortunately nobody
> has been working on it for a long time.
>
> 2) Even if this list exists, the other problem Fernando mentioned is
> that it is impossible to tell the difference between someone who added a
> street without checking the details (number of lanes, cycleway, ...)
> that someone who checks a road and fill all tag that are not the same as
> the local default value.
> in this usecase, a key like defaults=checked would be interesting.
> or something like survey:date + survey=default
> otherwise, do not hesitate to suggest a way to indicate that you have
> checked the secondary tags on 200 roads in a city so that another
> contributor knows which street is completely described and which one is
> not. or how to make a one-year check to tag change in oneway street.
>
> My usecase is the trick of marking streetlights when I have completely
> finished a street. since the only one doing it around here, I always
> know witch are still to be done. there should be a more serious way to
> share this kind of information.
>
> Regards,
> Marc
> ___
> 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] cycleway:both=no in StreetComplete

[Matej Lieskovský]

I agree that this deserves a separate topic, but I want to respond to some
points you made.

I don't like the highway_defaults idea. Default values should be assumed
whenever they are not explicitly given. I don't think that a tag that
states "most of those are probably going to be correct" is useful. In
general, we don't even have a way of saying "everything is OK here". Feel
free to disagree, but I think that the most reasonable path is relying on
users reporting discrepancies. I'd simply apply the defaults everywhere
and, if someone notices an error, it will get fixed. Tagging "this default
is correct" will lead to the same DB bloat as not having defaults.

Using the most common value as default has a major problem:
the most common values are oneway=yes, tunnel=yes, ford=yes.
I think that exceptions to the rule should be tagged, leaving the majority
up for defaults.

I'm strongly in favour of dealing with the defaults on a local basis -
defining defaults for elements in a given administrative area would be a
good beginning, but letting us draw the extent of individual defaults would
(for example) give us an elegant way of tagging maxspeed=30 zones for free.

I think that data consumers would appreciate a system, that would fill in
the relevant defaults for them. I'm not entirely sure how to make it, but
it sounds doable. Worst case scenario would be a special server providing
an "extended" database.

As a final remark, I'd consider a two-level system:
Assumed values are reasonable defaults, but should be confirmed by an
explicit tag when possible.
Implied values are those that are almost certainly correct and only
exceptions should be tagged.

Assumed values are good for the consumers and can be implemented reasonably
safely. This will provide an opportunity to test some of the relevant
systems.
Implied values are what will make the database cleaner, but are more
debatable. I think they are going to be OK, provided that we are careful
about adding new ones.

On 5 January 2018 at 00:09, Fernando Trebien <fernando.treb...@gmail.com>
wrote:

> On Thu, Jan 4, 2018 at 9:57 AM, Matej Lieskovský
> <lieskovsky.ma...@gmail.com> wrote:
> > 1) If we try to add every possible tag to every element, the DB will be
> > immense and the OWG will try to kill us. Imagine every road having access
> > tags. Should roads have tunnel=no?
>
> I will digress a bit, as I believe this should be a separate topic.
>
> We could define a tag such as highway_defaults=yes to express that a
> certain number of default values have been throughly verified by a
> mapper, and assume that any difference from those defaults will be
> mapped by adding extra tags. It could also be automatically inserted
> by bots once all tags in the default tags set have been added.
>
> So highway_defaults=yes could include things such as:
> - oneway=no for all highway types except motorway and motorway_link,
> for which oneway=yes
> - cycleway=no (implying cycleway:left=no, cycleway:right=no and
> cycleway:both=no) for all highway types
> - surface=asphalt (and perhaps lit=yes) for highway=cycleway
> - tunnel=no, bridge=no, lit=yes, embankment=no, cutting=no, ford=no,
> ice_road=no for all highway types
>
> And much more. In fact, the most common value (as reported by TagInfo
> or as implied by experience) for every tag could be the default value
> (subject to periodic review). A few ideas that come to my mind
> immediately:
> - access=* as defined in the Default table here:
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Acc
> ess-Restrictions#Default
> - shoulder=no, parking:lane:both=parallel, sidewalk=both,
> tactile_paving=no, wheelchair=yes for local public urban highway types
> (residential, living street)
> - surface=asphalt, smoothness=excellent for non-local highway types
> (unclassified, tertiary, secondary, primary, trunk, motorway)
> - shoulder=yes, sidewalk=no for motorway and motorway_link and perhaps
> trunk and trunk_link
> - service=driveway for highway=service
> - tracktype=grade3 for highway=track
> - wall=no for buildings and landuse
> - material=wood for power towers and power poles
> - frequency=50 for power lines
>
> We would also have to contact the developers of several important apps
> to request support for such a tag. In the case of cycleways, that
> would be Thunderforest / OpenCycleMap. For the other tags, ITO World
> comes to my mind. And of course, StreetComplete too. And iD still
> needs to warn the user about absent tags when combining ways. And we
> have to update the wiki article of several tags to list their default
> values. That's a ton of work, but if database efficiency and mapper
> effort is a concern, maybe it's worth doing. (I honestly think it is,
> but it requires more discussion an

Re: [Tagging] Short-term parking zones

[Matej Lieskovský]

+1 for a separate group

On 16 January 2018 at 23:03, Kevin Kenny 
wrote:

> On Tue, Jan 16, 2018 at 3:58 PM, Tod Fitch  wrote:
>
>> On Jan 16, 2018, at 9:43 AM, Paul Johnson  wrote:
>> On Jan 16, 2018 05:36, "Stefan Nagy"  wrote:
>>
>> Am 16.01.2018 12:10 schrieb marc marc:
>>
>>> we probably need to work on "default values".
>>> but no one seems motivated to work on the proposal.
>>>
>>
>> Is 'default values' a better word for what I called 'implicit values'
>> before or are you talking about something else?
>>
>>
>> That's how I read it.  Would be handy for situations that frequently come
>> up, like the speed limit of an area unless otherwise posted being a
>> specific value, or like U turns being blanket banned anywhere with a
>> traffic light in the City of Tulsa and State of Oregon.
>>
>>
>> I think I’ve seen the question of setting defaults come up several times
>> on this list and never get traction. I personally think they’d be a good
>> thing to simplify tagging.
>>
>> Just yesterday I felt obligated when putting a maxspeed tag on some
>> residential streets resorted to also adding a source:maxspeed="California
>> vehicle code 22352”. Paragraph 22352 in the California vehicle code
>> indicates, among other things, that a unsigned a residential street has a
>> 25 mph speed limit. It would be much easier and more encompassing to be
>> able to add a tag to the boundary relation for California to indicate the
>> default speeds for various highway classes in the state. Not a big deal for
>> motorways as there are only a few tens of thousands of miles of those, but
>> there has to millions of miles of residential roads in California with many
>> (most?) being unsigned. But being unsigned won’t stop you from getting a
>> ticket for exceeding the prima facia speed limit so routers and navigation
>> guidance applications ought to know about it.
>>
>
> That's a great idea - if we can pick up after the TIGER. Far too many
> rural roads are 'highway=residential' otherwise. The TIGER import's highway
> classes are NOT grounded in reality.
>
> Nevertheless, for instance, my township has a speed limit of 30 mph except
> as posted, and (again except as posted) no on-street parking from midnight
> to 6am following a four-inch snowfall. I've never tried to tag any of that
> sort of regulatory information, but I can imagine that applying it to all
> the streets in the town would be both tedious and unmanageable (the latter
> because if the town were to change the ordinance, it would mean updates to
> many hundreds of highway segments). That stuff wouldn't depend on highway
> class at all, just on whether the road segment is in the township.
>
>
>
> ___
> 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] Short-term parking zones

[Matej Lieskovský]

Ok, once again: I am sorry for even mentioning something that is actually
documented on the wiki. I've since then thought about the data model and I
can see how problematic it would be. Can we please move on to finding a
solution?

On 16 January 2018 at 09:25, Simone Saviolo <simone.savi...@gmail.com>
wrote:

> 2018-01-15 11:07 GMT+01:00 Martin Koppenhoefer <dieterdre...@gmail.com>:
>
>> > On 14. Jan 2018, at 12:32, Matej Lieskovský <lieskovsky.ma...@gmail.com>
>> wrote:
>> >
>> > If you create a single empty relation with the details of the parking
>> zone rules,
>> > you can then tag every road with the id of the relation.
>> > It is basically a way of flipping the relation system around,
>>
>> problem is with the following mappers, how would they find out there is
>> such a relation and that they should add it to the road they newly added?
>> If this kind of mapping started to become more established I imagine people
>> would spend a lot of time looking for those empty relations with the tags?
>>
>
> Not to mention that it would make for very poor data quality. It would
> establish a user-maintained (or rather, to-be-maintained) relationship
> between data; it would go over the software's head, and the database
> wouldn't know the least bit about it. From a practical point of view, when
> would an empty relation be downloaded? Never, if it has no members: which
> means that mappers would generally be anaware that such a thing even
> exists.
>
> In conclusion, you're suggesting a method that the machine couldn't help
> us with, and that mappers would have a very hard time (if not impossible)
> using correctly.
>
> Regards,
>
> Simone
>
> ___
> 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] Short-term parking zones

[Matej Lieskovský]

Greetings,

if you group all the streets in a single relation, the relation is likely
to be rather big.
This can be hard on the server.
If you create a single empty relation with the details of the parking zone
rules,
you can then tag every road with the id of the relation.
It is basically a way of flipping the relation system around,
which works well if you have a relation with a lot of tags and members
but every member would only be in a single such relation.
It also makes it a little more obvious that a given road is in the relation.

(I admit it is a somewhat less common way of tagging)

Happy mapping,

Matej

On 14 January 2018 at 12:21, Stefan Nagy <stefan.n...@posteo.net> wrote:

> Hello,
>
> Am 14.01.2018 12:00 schrieb Matej Lieskovský:
>
>> If those zones are not entire areas then I agree - don't use areas. If
>> it is on a street-by-street basis we have no choice but to track
>> individual streets.
>> How about an empty relation?
>> (https://wiki.openstreetmap.org/wiki/Empty_relations [1]) This would
>> group the tags in one place, leaving just a few tags per street.
>>
>
> I don't really get that since the roads are no relations but ways…
> Why shouldn't I add all the streets wich are part of the short-term
> parking zone to a relation type=site (site=parking) and then tag the
> relation with the needed attributes?
>
> Thanks,
>
> Stefan.
>
>
> --
> E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Short-term parking zones

[Matej Lieskovský]

Citation provided:
https://wiki.openstreetmap.org/wiki/Relation#Size
https://wiki.openstreetmap.org/wiki/Relation:route#Size

Notice that the border relation you linked is already version 790 (and
borders change far less often than roads). Viewing the relation on osm.org
already takes some time on my PC, I'd hate to have to import it into JOSM.
If you don't think that is bad enough, try working with this relation:
https://osm.org/relation/912311

On 14 January 2018 at 14:45, Mateusz Konieczny <matkoni...@gmail.com> wrote:

> On Sun, 14 Jan 2018 12:32:02 +0100
> Matej Lieskovský <lieskovsky.ma...@gmail.com> wrote:
>
> > if you group all the streets in a single relation, the relation is
> > likely to be rather big.
> > This can be hard on the server.
>
> [citatation needed]
>
> We have massive boundary relation
> ( https://www.openstreetmap.org/relation/49715 for example) and AFAIK
> everything works fine.
>
> Is this performance concern is confirmed by anything? Messages from
> people handling OSM servers, profiling, anything like that?
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Short-term parking zones

[Matej Lieskovský]

Greetings,

If those zones are not entire areas then I agree - don't use areas. If it
is on a street-by-street basis we have no choice but to track individual
streets.
How about an empty relation? (
https://wiki.openstreetmap.org/wiki/Empty_relations) This would group the
tags in one place, leaving just a few tags per street.

Happy mapping!

Matej

On 14 January 2018 at 11:51, Stefan Nagy <stefan.n...@posteo.net> wrote:

> Hi,
>
> Am 14.01.2018 11:02 schrieb pbnoxious:
>
>> On 2018-01-13 22:06, Matej Lieskovský wrote:
>>
>>> I have a similar problem with the tagging of "Zone 30" and other such
>>> restrictions.
>>>
>>> I understand that having the tag on every road makes it easier for
>>> consumers. I think that when a restriction is conceptually an area, it
>>> should be marked as an area because we should be making use of
>>> the fact that we have a geospatial database.
>>> A relationship feels a little like having the disadvantages of both
>>> approaches - you need to keep track of all road segments, but it is
>>> worse for consumers.
>>>
>>
>> I'd like to disagree on the "Zone 30" being an actual area: Here the
>> appropriate administration does usually not set a full area (with all
>> houses, parks etc.) as restricted but rather the individual connected
>> streets, which means that in my mind a relation would be the approach
>> that resembles the nature of these restrictions the most. But as you
>> already noticed: the relation does not really make things easier, so I
>> would rather stick to tagging the individual roads.
>>
>
> The problem with short-term parking zones is that the conditions are
> much more complicated than in 30 km/h zones… For example from x pm
> to y am parking is free for everyone. From y am to x pm it's only free for
> residents (they get a special sticker for their car), everyone else has to
> pay a fee of z euros and they are only allowed to park for max. 2 hours.
>
> Now tag nearly every street in a district with this information – and when
> you're done the city decides to change the rules for it's short-term
> parking zones…
>
> That's why I'd like to use implicit values or relations. I don't want to
> use
> areas because, as you say, "the appropriate administration does usually
> not set a full area (with all houses, parks etc.) as restricted but rather
> the
> individual connected streets" – and the rules don't apply to all streets in
> these areas.
>
> Cheers,
> Stefan.
>
>
> --
> E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Nonbreakable spaces in name tags

[Matej Lieskovský]

Greetings!

Several Slavic languages have rather formal rules about line breaks.
We in Czechia have a few contributors who take the time to add
nonbreakable spaces to names that "need" them. Needless to say, the
current situation is rather inconsistent, with nonbreakable spaces
occurring in the data but nowhere near being reliable. The local talk
is also divided on the topic of whether nonbreakable spaces should be
encouraged or removed.

We know that at least some renderers (including osm.org) actually make
use of the nonbreakable spaces. Nominatim does Unicode collation,
handling nonbreakable spaces well. Overpass does not and its
suspicious behaviour was what alerted us to the problem in the first
place.

Both having and not having nonbreakable spaces has its pros and cons.
The current state of uncertainty is the worst of both worlds. In an
attempt to find a resolution and prevent an edit war, we reached out
to the DWG, which did not solve the dispute. We now ask for opinions
here.

Thank you in advance,
Matej Lieskovský

PS: The rules are formal enough that there exists a 1997 program
"Vlna" ("Tilde"), that can add nonbreakable spaces to TeX source files
and is commonly used for important documents.

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

Re: [Tagging] Nonbreakable spaces in name tags

[Matej Lieskovský]

In Czech, a nonbreakable space should follow any single-letter
preposition or conjunction and academic or military titles. A
nonbreakable space should also be used due to some common
contractions, between a number and a unit, and around some punctuation
marks.

I noticed that some Overpass queries were not returning some elements
- that is how I found out that we actually have a rather large number
of nonbreakable spaces in the data.

Nonbreakable spaces are currently quite troublesome - not all
consumers actually use Unicode collation, it is invisible in JOSM and
it is not exactly easy to input. Also, the chance that we convince all
contributors to use it correctly is exactly zero. Along with this
potentially being "tagging for the renderer", there are many calls for
a mass-removal.

On the other hand, there is software that actually handles Unicode
collation well and it does make the correct rendering of names an
order of magnitude easier. Leaving this up to the renderer sounds
logical, but imagine forcing every renderer to figure out what
language any given name is in and then running the appropriate
subprogram to fill in the nonbreakable spaces. This could require
semantic analysis due to the need to add a nonbreakable space after
the "V" in "V jámě" (preposition) but before the "V" in "Jiří V."
(roman ordinal number) and after the "V." in "V. Špidla" (contraction
of name (and yes, there are cases when you should use a contraction)).

Nonbreakable spaces are strange - you cannot reliably tell if they are
used OTG (but in some cases you can), official documents often ignore
them (leaving them up to the automated systems in office software, so
they do occur sometimes) and the rules governing them are older than
computers, so asking if they are a rule or a character is... dubious.

And yes, we do have really long names of things. Names of POIs named
after people are a common use case.

Matej

On 26 January 2018 at 16:11, marc marc <marc_marc_...@hotmail.com> wrote:
> Le 26. 01. 18 à 15:48, Matej Lieskovský a écrit :
>> Several Slavic languages have rather formal rules about line breaks.
>
> it depends on whether it is a grammar rule or a "char".
> In French, it is a rule to know how to cut a word at the end of a line.
> Since it's a grammar rule, I don't see any point in adding a character
> between syllables to describe it. it's up to the render
> to know when it can do it if ppl wants this feature.
> I know nothing about your language, but I feel it look like the same.
> If my understanding is correct, I am in favour of not putting
> this "nonbreakable" information into a value and moving it to app code
> that need it (witch ? have you so long value that's needed to break it
> in several line ?)
>
> Regards,
> Marc
> ___
> 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] Nonbreakable spaces in name tags

[Matej Lieskovský]

@marc: I just realized - I'm not talking about breaking words between
syllables but about breaking lines between words. It is not adding a
character, just using a nonbreakable version of a space. Sorry if I'm
not being clear.

On 26 January 2018 at 16:47, Matej Lieskovský
<lieskovsky.ma...@gmail.com> wrote:
> In Czech, a nonbreakable space should follow any single-letter
> preposition or conjunction and academic or military titles. A
> nonbreakable space should also be used due to some common
> contractions, between a number and a unit, and around some punctuation
> marks.
>
> I noticed that some Overpass queries were not returning some elements
> - that is how I found out that we actually have a rather large number
> of nonbreakable spaces in the data.
>
> Nonbreakable spaces are currently quite troublesome - not all
> consumers actually use Unicode collation, it is invisible in JOSM and
> it is not exactly easy to input. Also, the chance that we convince all
> contributors to use it correctly is exactly zero. Along with this
> potentially being "tagging for the renderer", there are many calls for
> a mass-removal.
>
> On the other hand, there is software that actually handles Unicode
> collation well and it does make the correct rendering of names an
> order of magnitude easier. Leaving this up to the renderer sounds
> logical, but imagine forcing every renderer to figure out what
> language any given name is in and then running the appropriate
> subprogram to fill in the nonbreakable spaces. This could require
> semantic analysis due to the need to add a nonbreakable space after
> the "V" in "V jámě" (preposition) but before the "V" in "Jiří V."
> (roman ordinal number) and after the "V." in "V. Špidla" (contraction
> of name (and yes, there are cases when you should use a contraction)).
>
> Nonbreakable spaces are strange - you cannot reliably tell if they are
> used OTG (but in some cases you can), official documents often ignore
> them (leaving them up to the automated systems in office software, so
> they do occur sometimes) and the rules governing them are older than
> computers, so asking if they are a rule or a character is... dubious.
>
> And yes, we do have really long names of things. Names of POIs named
> after people are a common use case.
>
> Matej
>
> On 26 January 2018 at 16:11, marc marc <marc_marc_...@hotmail.com> wrote:
>> Le 26. 01. 18 à 15:48, Matej Lieskovský a écrit :
>>> Several Slavic languages have rather formal rules about line breaks.
>>
>> it depends on whether it is a grammar rule or a "char".
>> In French, it is a rule to know how to cut a word at the end of a line.
>> Since it's a grammar rule, I don't see any point in adding a character
>> between syllables to describe it. it's up to the render
>> to know when it can do it if ppl wants this feature.
>> I know nothing about your language, but I feel it look like the same.
>> If my understanding is correct, I am in favour of not putting
>> this "nonbreakable" information into a value and moving it to app code
>> that need it (witch ? have you so long value that's needed to break it
>> in several line ?)
>>
>> Regards,
>> Marc
>> ___
>> 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] Nonbreakable spaces in name tags

[Matej Lieskovský]

@Erkin: Yes, but the full form can contain a contraction. There is an
public transport stop in Prague called "I. P. Pavlova" and (unlike the
nearby "náměstí Ivana Petroviče Pavlova") it is ALWAYS written as an
abbreviation. Signs, official documents, spoken language... there is a
point after which it would be wrong to expand the name.

https://www.openstreetmap.org/node/25936016

Matej

On 26 January 2018 at 19:09, Erkin Alp Güney  wrote:
>> (and yes, there are cases when you should use a contraction)
> name=* is full form. Not abbreviated in any way.
>
> Yours, faithfully
> Erkin Alp
>
> ___
> 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] Short-term parking zones

[Matej Lieskovský]

Hello!

I have a similar problem with the tagging of "Zone 30" and other such
restrictions.

I understand that having the tag on every road makes it easier for
consumers.
I think that when a restriction is conceptually an area, it should be
marked as an area
because we should be making use of the fact that we have a geospatial
database.
A relationship feels a little like having the disadvantages of both
approaches -
you need to keep track of all road segments, but it is worse for consumers.

I'd like to know, if there is some generic way of tagging an area-based
restriction.
I know we already use it for low emission zones, but I'd like a general
version.
I understand the need for consumer-friendly tagging,
but couldn't we somehow solve that without tagging everything separately?

Full disclosure: I am a proponent of a system that would take a planet file
and apply some transformation rules in order to "decompress" it for
consumer use.
Stuff like "every road in this area is a 50km/h with source=cz:urban unless
otherwise stated".

Matej Lieskovský

On 13 January 2018 at 20:21, Stefan Nagy <stefan.n...@posteo.net> wrote:

> Hi,
>
> in Vienna, Austria parking space management has turned entire districts
> or large connected parts thereof into short-term parking zones (see [1]).
>
> To me it seems that there has to be a better way to map these zones than
> to tag every street therein with the same (sometimes quite complicated)
> parking:condition-tags. And since Vienna isn't the only city with big
> short-term parking zones I wanted to ask for ways how to solve this
> problem.
>
> First I was thinking about implicit parking:condition-values used on all
> streets in these zones, something like
> parking:condition:both=AT:ViennaSTPZx ('x' because right now there are
> three different short-term parking zones in Vienna), in this case I thought
> we could document these implicit values in the wiki. Then on the Austrian
> mailinglist (german thread '[talk-at] Wiener Kurzparkzonen', see [2]) the
> idea
> was brought up that we could use relations with all streets in these zones.
> Maybe type=site relations with parking:condition-tags…?
>
> I hope someone here was confronted with a similar problem before and
> found a good way to map big parking zones.
>
> Thanks,
> Stefan.
>
>
> [1] https://www.wien.gv.at/english/transportation/parking/shortterm.htm
> [2] https://lists.openstreetmap.org/pipermail/talk-at/2018-Janua
> ry/thread.html
>
> --
> E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Short-term parking zones

[Matej Lieskovský]

Upon further analysis of empty relations, I suspect they will be far more
problematic than I expected. While it is on the wiki since 2010 and feels
like a powerful tool, it does not seem to be used (let alone supported by
consumers).

My bad, I should not recommend things that I have not used myself.

I am curious as to the recommended approach - we have a similar parking
zone system here in Prague and I have no idea how to map it. A relation
still sounds like a horrible solution due to the parking depending on the
side of the road and due to the sheer frequency of road splits due to (for
example) added surface tags.

Maybe a wikidata tag?

On 14 January 2018 at 15:05, Matej Lieskovský <lieskovsky.ma...@gmail.com>
wrote:

> Citation provided:
> https://wiki.openstreetmap.org/wiki/Relation#Size
> https://wiki.openstreetmap.org/wiki/Relation:route#Size
>
> Notice that the border relation you linked is already version 790 (and
> borders change far less often than roads). Viewing the relation on osm.org
> already takes some time on my PC, I'd hate to have to import it into JOSM.
> If you don't think that is bad enough, try working with this relation:
> https://osm.org/relation/912311
>
> On 14 January 2018 at 14:45, Mateusz Konieczny <matkoni...@gmail.com>
> wrote:
>
>> On Sun, 14 Jan 2018 12:32:02 +0100
>> Matej Lieskovský <lieskovsky.ma...@gmail.com> wrote:
>>
>> > if you group all the streets in a single relation, the relation is
>> > likely to be rather big.
>> > This can be hard on the server.
>>
>> [citatation needed]
>>
>> We have massive boundary relation
>> ( https://www.openstreetmap.org/relation/49715 for example) and AFAIK
>> everything works fine.
>>
>> Is this performance concern is confirmed by anything? Messages from
>> people handling OSM servers, profiling, anything like that?
>>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging for an American Wild & Scenic river

[Matej Lieskovský]

Brad is right: Wild, Scenic and Recreational rivers are already
defined as protect_class=5. Use the protection_title tag to specify
the exact type of protection.
Cheers,
Matej

On 3 February 2018 at 06:56, Brad Neuhauser  wrote:
> "Wild and Scenic River" is specifically mentioned on the wiki as
> boundary=protected_area, protect_class=5. Look at the table for
> nature-protected areas, and scroll down to the US section. Cheers, Brad
>
> On Fri, Feb 2, 2018 at 10:47 PM, Kevin Kenny 
> wrote:
>>
>> On Fri, Feb 2, 2018 at 9:54 PM, Graeme Fitzpatrick 
>> wrote:
>>>
>>> On 3 February 2018 at 12:00, Kevin Kenny 
>>> wrote:

 On Fri, Feb 2, 2018 at 7:44 PM, Dave Swarthout 
 wrote:
>
> I asked this question last week of the OSM Help community:
>
> I'm looking for tagging that will indicate that a particular river in
> the United States is a "Wild and Scenic River" as defined by the Wild &
> Scenic Rivers Act. I have searched with Overpass for waterway=* that also
> has a scenic=yes tag but it turned up no results. Can anyone provide some
> guidance and/or examples?
>
 Like you, I know of the Wild, Scenic and Recreational Rivers
 designations.
 Like you, I lack a good way to tag them.
 If nobody else has come up with anything - and do let's also ask on
 talk-us,
 since this is a peculiarly American designation - then let's invent
 something
 and Wikify it.

>>> Without knowing the details of just what a "Wild Scenic" river is, could
>>> you use the nature=conservation tag in conjunction with waterway=?
>>
>>
>> Wild and Scenic Rivers are linear protected areas designated by statute in
>> the US.  https://www.rivers.gov/
>>
>> Designating the waterway itself is a good start, but Wild and Scenic
>> Rivers (also Recreational Rivers in New York State) generally also have
>> associated corridors that should have some sort of boundary=protected_area
>> (and we can debate what protect_class might be appropriate) associated with
>> them.
>>
>> I'm aware of several rivers that are so designated that I've visited, but
>> I've not done the necessary research to figure out how to represent them and
>> their corridors. The Federal program has downloadable Public Domain data on
>> its web site that I have not examined.
>>
>> My home state of New York actually has very few of them that are Federally
>> designated - the Delaware, on the Pennsylvania line. This is because the
>> State anticipated the Federal government and came up with its own
>> designations http://www.dec.ny.gov/permits/32739.html and came up with its
>> own program to administer them http://www.dec.ny.gov/permits/6033.html.
>>
>> The Federal program is not universally loved:
>> https://www.flickr.com/photos/66934423@N00/10605220
>>
>>
>>
>>
>>
>> ___
>> 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] Nonbreakable spaces in name tags

[Matej Lieskovský]

So... can we reach some conclusion?

I have a particular situation I need to resolve - some streets consist
of ways that (among other, meaningful differences) vary in their usage
of non-breakable spaces. Here are the possible solutions:

1) Start removing nbsp from local data
2) In case of conflict, prefer the variant without nbsp
3) In case of conflict, choose the more common variant
4) In case of conflict, prefer the variant with (correctly placed) nbsp
5) Start adding nbsp to local data
6) Leave things as they are

To be perfectly honest, unless we can agree on whether nbsp should be
encouraged or removed, I will use option 4. Option 6 (status quo) is
pretty much the worst of both worlds, 5 is undeniably adding nbsp to
the data (and too much work for now), and an eventual conversion from
anything to 1 is trivial (which does not work for converting from 2 or
3 to 5). Since option 4 at least makes entire streets have the same
name without loss of data or adding nbsp to streets that are ok so
far, I consider it to be the best compromise in case of no consensus.

Matej Lieskovský

PS: I am starting to suspect that we might need a wiki page concerning
Unicode usage in general (nbsp, soft hyphens, roman numerals,
normalisation...). The link below does seem a little underwhelming:
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters

On 27 January 2018 at 01:50, Johnparis <ok...@johnfreed.com> wrote:
> HTML has  for non-breakable spaces (Unicode U+00A0).
>
> HTML has  for soft hyphens (Unicode U+00AD).
>
> --
>
> Message: 2
> Date: Fri, 26 Jan 2018 23:04:32 +0100
> From: Richard <ricoz@gmail.com>
> To: "Tag discussion, strategy and related tools"
> <tagging@openstreetmap.org>
> Subject: Re: [Tagging] Nonbreakable spaces in name tags
> Message-ID: <20180126220432.GA10615@rz.localhost.localdomain>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Fri, Jan 26, 2018 at 03:48:42PM +0100, Matej Lieskovský wrote:
>> Greetings!
>>
>> Several Slavic languages have rather formal rules about line breaks.
>
> the problem is much broader, sooner or later OSM rendering will hit word
> splitting.
>
>> PS: The rules are formal enough that there exists a 1997 program
>> "Vlna" ("Tilde"), that can add nonbreakable spaces to TeX source files
>> and is commonly used for important documents.
>
> probably not all OSM languaes have such tools and even if they have it can
> be tricky to determine which language rules to apply.
>
> I would think..
> * if someone wants to use nonbreakable spaces he should be allowed to do
>   so and tools should tolerate it (not necessarilly understand but not
>   break)
> * if someone wants to use explicit word-split marks/soft-hyphens
>   this should be somehow allowed too.
>
> Otherwise the software should try to do its best and apply heuristics to
> avoid
> splitting lines in wrong places.
> Not splitting 1000 034 should be obvious, roman numbers as well. Prefer not
> splitting around "lonely" characters.
> The rendering software can also compare texts with name tags and prefer not
> to split names at all.
>
> Richard
>
>
>
>
> ___
> 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] Nonbreakable spaces in name tags

[Matej Lieskovský]

@Marc:
Nominatim handles nbsp well.
Renderers seem to either ignore it or make use of it.
Most editors seem to handle it well, but whitespace highlighting would
be welcome.
Overpass... theoretically, it is doing exactly what it should be
doing. Somehow making it simpler to create a regex that does Unicode
collation would be nice.

Is there anything that literally breaks? I don't think not doing
Unicode collation at all is an excuse.

On 31 January 2018 at 19:43, Simon Poole  wrote:
>
>
> Am 31.01.2018 um 19:33 schrieb Simon Poole:
>> IMHO we should in general treat all unicode space variants as a nomal
> that should have been "normal"
>
>
>
> ___
> 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] 'Unknown' value.

[Matej Lieskovský]

(Without digging through the database) I suspect that might be caused
by the idea of default values... Imagine drawing a road. If you don't
tag it as 'oneway', it is assumed not to be a 'oneway'. If you
honestly don't know, you need to tag it with something like 'unknown'.
But that's just my guess - why not contact the author?

Matej

On 3 February 2018 at 19:18, Dave F  wrote:
> Hi
> I recently seen a variety of keys being given the value of 'unknown'.
> I'm struggling to see its purpose. It confirms nothing & adds no value to
> the database. Am I missing something?
>
> DaveF
>
> ___
> 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] Default values for residential roads and living streets

[Matej Lieskovský]

Mentioning defaults on the wiki is not machine-readable. We've been
talking about this for a while now - can someone please set up a
separate channel for a discussion about the mechanism for setting
defaults?

Matej Lieskovský

On 12 February 2018 at 22:28, Selfish Seahorse
<selfishseaho...@gmail.com> wrote:
>> I don't see how it would be possible to set a default global value.
>
> I thought that just mentioning them in the wiki would be enough (like
> the default access restrictions). But as residential roads with more
> than one lane seem to be common elsewhere, there is no need for such a
> global default value.
>
>
> On 12 February 2018 at 22:16, marc marc <marc_marc_...@hotmail.com> wrote:
>> Hello,
>>
>> Le 12. 02. 18 à 22:02, Selfish Seahorse a écrit :
>>> There were quite a few additions of cycleway:both=no and lanes=1 tags
>>> to residential roads and living streets recently, which makes me
>>> wonder if it might make sense to define cycleway:both=no and lanes=1
>>> as default values for highway=residential and highway=living_street on
>>> the wiki. What do you think about that?
>>
>> I don't see how it would be possible to set a default global value.
>> and even for a country-scale default value, here lanes=1 and lanes=2
>> are just as common.
>> If you think that a default value makes sense for a country, discuss it
>> with the country mailing. but as long as there is no mechanism to set
>> default values in osm, the info on the wiki page will still be useless
>> for applications that use the data. your wish therefore requires you to
>> work on the proposed feature "default values".
>>
>> For cycleway:both=no, setting this to the default value does not change
>> anything, what is missing is a way to make the difference between "this
>> route has the default values after verification" of "this route has not
>> been checked, let's suppose it is the default values as long as nobody
>> has filled accurate value".
>> If not, you should also remove surface=asphalt because it's the default
>> for a residential highway in a lot of country. also remove maxspeed, ...
>>
>> Regards,
>> Marc
>> ___
>> 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] departures_board vs. passenger_information_display

[Matej Lieskovský]

Greetings!

Czech railway stations have separate arrival and departure boards (and
entirely separate general information boards) that can be far enough apart
for the distinction being important. If you're standing in front of a
departure board, finding an arrival board might not be trivial.

Happy mapping!
Matej

On 26 February 2018 at 09:29, Johnparis  wrote:

> AgusQui has noticed that the two keys mentioned in the subject line are
> essentially duplicates.
>
> I think passenger_information_display is more useful, as it can include
> arrivals as well as departures. It also outnumbers departures_board by
> about six to one.
>
> The departures_board key does have a useful subkey of realtime. I would
> suggest adding the following multivalue options:
>
> passenger_information_display = yes/no/realtime/static
>
> ... where "static" would cover the printed versions proposed in the
> departures_board page. Alternatively it could be a subkey:
>
> passenger_information_display:realtime = yes/no
>
> I frankly don't find it useful to make a distinction between printed
> timetables with times vs. printed timetables with intervals (Paris mixes
> the two anyhow).
>
> If folks think this is a good idea (and making departures_board
> deprecated), I could write up a formal proposal.
>
> John
>
> ___
> 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] Variable position

[Matej Lieskovský]

I respectfully disagree.

The benches are there, quite probably within 10m of their location in the
map. While this is abysmal accuracy, it is not entirely wrong. Isn't "there
aren't any known benches here" a worse information than being 10m off?

That same park has several stone benches that do not move. Let's say that I
tag the park with "bench=yes". So there is a park with "bench=yes" and
"bench:material=wood" that contains several "amenity=bench" with
"material=stone". I can imagine this would be rather confusing even to a
human.

Do we have a landuse=bench tag? Do we really want one? It does not feel
like the right key... But yes, some way of saying "there are 15 benches
somewhere in this area" sounds like a reasonable solution. Not sure if
better, but at least usable.

A "position=variable" tag feels more natural, but I do agree that it is far
from perfect.

On 28 December 2017 at 12:27, marc marc <marc_marc_...@hotmail.com> wrote:

> Le 28. 12. 17 à 11:05, Matej Lieskovský a écrit :
> > If we mark the object with a note:
> >   - an unaware data consumer will see the object with an inaccurate
> position
>
> your proposal has the same defect as those that create objects that do
> not exist (highway or building for example) and that add tags
> (in_use=no, construction=yes, state=proposed) to say that the main
> information is wrong, hopping that everbody else 'll parse additional
> tag to have the correct meaning.
>
> Osm is a geographical database, not an inventory. therefore by default
> it can be expected that an object is at its position. if this is not the
> case and if you don't like the idea of making an area for the position
> where it is, I think you will have to use a namespame like variable: in
> order not to mislead the 99.99% of uses that ignore your new tag.
> yet when I compare with existential functions, a restaurant for example,
> you don't put a node in every place where there is a seat, you put the
> info on the poi with outdoor_seating tag
> https://wiki.openstreetmap.org/wiki/Key:outdoor_seating
> For a bus stop or a shetler, we use bench=yes
> https://wiki.openstreetmap.org/wiki/Key%3Abench
> you can draw an area to delimit the location of the benches and add the
> corresponding lander/lancover/leisure tag
> can it not fill for your need without giving wrong info that parse major
> tags ?
>
> Regards,
> Marc
> ___
> 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] Variable position

[Matej Lieskovský]

I've thought about it and I believe the option with a note is better.

If we tag it on the area:
 - an unaware data consumer will see just some strange tags
 - an informed data consumer will know "somewhere in there"

If we mark the object with a note:
 - an unaware data consumer will see the object with an inaccurate position
 - an informed data consumer will know "somewhere around there"

With the exception of data consumers who rely on accurate positions (which
is a dangerous thing to do with OSM), an (reasonably) inaccurate position
seems better than no position. If I want to find a bench, getting a
position 10m off seems better than not seeing any. Also, tagging on the
area will likely be messy - I might want to add a lot of details about a
bench, which would result in tons of tags on the area, which would require
something like ":bench" and so on... Finally, an object with a note can
give a bit more information - while the fact that a bench will not leave
the park and a BWE will stay in the mine is somewhat intuitive, expressing
"benches are usually along these three paths" would be nigh impossible with
a tag on an area.

Thing is, notes are meant to be human readable, not machine readable. Notes
can contain other information and are harder to look for typos in. Couldn't
we agree on a tag for these objects? Something like "position=variable"?

On 25 December 2017 at 23:15, Graeme Fitzpatrick 
wrote:

>
> On 25 December 2017 at 01:46, Michal Fabík  wrote:
>
> Can anybody think of other examples like this?
>
>
> Cranes?
>
> I was thinking about Hammerhead cranes that are used on (usually)
> high-rise construction sites & are in place for maybe 12 months (+/-) at a
> time, depending on duration of construction. These are also visible from
> quite a distance to give a navigation reference, although, of course,
> they're usually found in built-up areas (& are also on construction sites,
> which will also be marked as such in OSM! :-))
>
> Also just thought about dockside cranes for loading shipping containers.
> They would always be on this particular dock, but may travel up & down
> along the length of the dock?
>
> Thanks
>
> Graeme
>
> ___
> 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] Kerbs

[Matej Lieskovský]

I'd use "normal" or "regular", leaving "raised" for "above the norm". Both
values are quite rare, but I guess that is because most will simply not tag
it. Or (as the wiki discussion suggests) use kerb:height in cm.

Looks like that wiki page could use updating...

Matej Lieskovský

On 28 December 2017 at 22:25, Nick Bolten <nbol...@gmail.com> wrote:

> This kind of info is actually very relevant to all kinds of different
> pedestrians. There are manual wheelchair users with serious athleticism who
> are happy with moderate curbs, but can't do tall ones (due to physics -
> they'd tip before getting over), people with limited mobility who use
> walkers/canes and can't do large displacements, people using very fancy
> (and expensive) electric wheelchairs that can handle relatively high curbs,
> etc. If you add kerb:height info, it could be very useful to someone,
> eventually!
>
> On Thu, Dec 28, 2017 at 1:07 PM Selfish Seahorse <
> selfishseaho...@gmail.com> wrote:
>
>> On 28 December 2017 at 20:29, Martin Koppenhoefer
>> <dieterdre...@gmail.com> wrote:
>>
>> > I think it makes a difference to many wheelchair users or cyclists or
>> automobilists or most other vehicles and pedestrians whether the kerb is 12
>> or 30 centimeters (assuming that meters was a typo, right?).
>> >
>> > Regarding the tag raised kerb seems ok for both types of kerbs though.
>>
>> Yes, centimetres. Sorry, this was a mistake.
>>
>> And I was thinking of pedestrian crossings and that it doesn't make a
>> difference there (though, actually, I've never seen a pedestrian
>> crossing with a kerb of 30 cm height).
>>
>> ___
>> 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] cycleway:both=no in StreetComplete

[Matej Lieskovský]

While considering the absence of a value to imply that it is unknown is an
elegant solution theoretically, I think it has two major problems:
1) If we try to add every possible tag to every element, the DB will be
immense and the OWG will try to kill us. Imagine every road having access
tags. Should roads have tunnel=no?
2) Data consumers will sometimes still need to guess the value, which means
a default still needs to be known.

I'd like to have a larger discussion about implied and assumed tags,
because this is becoming a major problem.

On 4 January 2018 at 02:22, Fernando Trebien 
wrote:

> Tag absence has never been defined clearly in OSM. Some think of it as
> meaning "the tag has the default value," others think "the value of the tag
> is still unknown," which seems to be the most common understanding (that's
> why noname=* exists).
>
> I always add tags in their default value to express that the value is
> known and has been surveyed, cycleways included. (though in the case of
> cycleways I usually only add them around existing cycleways to avoid
> confusion and to prevent mappers - especially those using iD - from
> combining sequential ways without getting a warning)
>
> Em 25 de dez de 2017 23:34, "Dave Swarthout" 
> escreveu:
>
>> This sounds similar to those that suggested adding oneway=no to all
>> streets that are not explicitly tagged as oneway=yes. All roads without
>> cycleways could conceivably be tagged this way.
>> Unless there is some cause for such a tag, for example, noting that a
>> cycleway once existed here but is no longer present, this tag is totally
>> unnecessary and adds needless data to OSM.
>>
>> On Tue, Dec 26, 2017 at 6:50 AM, marc marc 
>> wrote:
>>
>>> Hello,
>>>
>>> Le 26. 12. 17 à 00:22, Dave F a écrit :
>>>
>>> > There's been quite a few recent additions of 'cycleway:both=no' being
>>> > added by users of StreetComplete.
>>> >
>>> > http://www.openstreetmap.org/way/8609990
>>> >
>>> > There's no mention of this tag on the wiki & to me appears a bit
>>> > ambiguous. Most (all?) are the sole cycle tag on the entity. Both=no
>>> > suggests that a cycleway could exist in one direction.
>>>
>>> I agree that cycleway:both=no is not a good tag.
>>> cycleway=no is better.
>>>
>>> > What is the reason the developers aren't using the established tagging
>>> > scheme:
>>> > https://wiki.openstreetmap.org/wiki/Key:cycleway
>>>
>>> ask the dev :)
>>>
>>> > Note under 'cycleway=no' as a tag of "dubious usefulness".
>>>
>>> I could help to see what road have been surveyed and somebody see that
>>> this road doesn't have a cycleway. Put in urban area, it's a (minor)
>>> added value. Without a cycleway tag, the cycleway is unknown.
>>>
>>> > This email has been checked for viruses by Avast antivirus software.
>>>
>>> it's also a dubious usefulness :)
>>>
>>> Regards,
>>> Marc
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>>
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>>
>> ___
>> 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