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

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

Re: [Tagging] Variable position

2017-12-31 Thread Matej Lieskovský
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. De

[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),

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

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

2018-01-05 Thread Matej Lieskovský
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.co

Re: [Tagging] default value

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

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

2018-01-04 Thread Matej Lieskovský
.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 > &g

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"

Re: [Tagging] Short-term parking zones

2018-01-16 Thread Matej Lieskovský
avi...@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

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Short-term parking zones

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

[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 <marc_marc_...@hotmail.com> wrote: > Le 26. 01.

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ý <lieskovsky

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] Short-term parking zones

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

Re: [Tagging] Short-term parking zones

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

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

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] '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 <selfishse

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

Re: [Tagging] Variable position

2017-12-28 Thread Matej Lieskovský
s 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 ob

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

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 updat

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.