[Tagging] Nonbreakable spaces in name tags

2018-01-26 Thread Matej Lieskovský
nd 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 sou

Re: [Tagging] Nonbreakable spaces in name tags

2018-01-26 Thread Matej Lieskovský
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 wrote: > Le 26. 01. 18 à 15:48, Matej Lieskovský a écrit

Re: [Tagging] Nonbreakable spaces in name tags

2018-01-26 Thread 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ý wrote: >

Re: [Tagging] Nonbreakable spaces in name tags

2018-01-26 Thread 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

Re: [Tagging] Nonbreakable spaces in name tags

2018-01-31 Thread Matej Lieskovský
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

Re: [Tagging] Nonbreakable spaces in name tags

2018-01-31 Thread 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

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

2018-02-03 Thread 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 > b

Re: [Tagging] 'Unknown' value.

2018-02-03 Thread 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

Re: [Tagging] Default values for residential roads and living streets

2018-02-12 Thread 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 wrote: >>

Re: [Tagging] departures_board vs. passenger_information_display

2018-02-26 Thread 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

[Tagging] Variable position

2017-12-23 Thread 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), l

Re: [Tagging] Variable position

2017-12-28 Thread 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 objec

Re: [Tagging] Variable position

2017-12-28 Thread Matej Lieskovský
" tag feels more natural, but I do agree that it is far from perfect. On 28 December 2017 at 12:27, marc marc 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

Re: [Tagging] Kerbs

2017-12-28 Thread 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

Re: [Tagging] Variable position

2017-12-31 Thread Matej Lieskovský
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" wrote: > > > sent from a phone > > > On 28. Dec 2017, at 14:06, Matej Lieskov

Re: [Tagging] Kerbs

2017-12-31 Thread 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 mig

Re: [Tagging] emergency bays - which side?

2017-12-31 Thread 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 >> b

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

2018-01-04 Thread 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. Shoul

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

2018-01-04 Thread Matej Lieskovský
d 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

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

2018-01-05 Thread Matej Lieskovský
mes 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ý > wrote: > > I agree that this deserves

Re: [Tagging] default value

2018-01-05 Thread Matej Lieskovský
consensus. On 5 January 2018 at 13:44, marc marc 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

Re: [Tagging] Kerbs

2018-01-07 Thread 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

Re: [Tagging] Short-term parking zones

2018-01-13 Thread Matej Lieskovský
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 wrote: > Hi, > > in Vienna, Austri

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Matej Lieskovský
place, leaving just a few tags per street. Happy mapping! Matej On 14 January 2018 at 11:51, Stefan Nagy 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 &qu

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Matej Lieskovský
) Happy mapping, Matej On 14 January 2018 at 12:21, Stefan Nagy 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 t

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Matej Lieskovský
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 wrote: > On Sun, 14 Jan 2018 12:32:02 +0100 > Matej Lieskovský wrote: > >

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Matej Lieskovský
example) added surface tags. Maybe a wikidata tag? On 14 January 2018 at 15:05, Matej Lieskovský wrote: > Citation provided: > https://wiki.openstreetmap.org/wiki/Relation#Size > https://wiki.openstreetmap.org/wiki/Relation:route#Size > > Notice that the border relation you li

Re: [Tagging] Short-term parking zones

2018-01-16 Thread Matej Lieskovský
18-01-15 11:07 GMT+01:00 Martin Koppenhoefer : > >> > On 14. Jan 2018, at 12:32, Matej Lieskovský >> 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

Re: [Tagging] Short-term parking zones

2018-01-16 Thread 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