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
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
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
is there a way to map objects, whose position changes slightly?
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),
I'd say the first picture is a flush kerb followed by a ramp.
On 7 January 2018 at 20:12, Selfish Seahorse
> 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
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ý
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
> 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
+1 for a separate group
On 16 January 2018 at 23:03, Kevin Kenny
> 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"
> 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>
>> > If you create a single empty relation with the details
On 14 January 2018 at 12:21, Stefan Nagy <stefan.n...@posteo.net> wrote:
> 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
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:
On 14 January 2018 at 14:45, Mateusz Konieczny <matkoni...@gmail.com> wrote:
> On Sun, 14 Jan 2018 12:32:02 +0100
, leaving just a few tags per street.
On 14 January 2018 at 11:51, Stefan Nagy <stefan.n...@posteo.net> wrote:
> Am 14.01.2018 11:02 schrieb pbnoxious:
>> On 2018-01-13 22:06, Matej Lieskovský wrote:
>>> I have a similar problem
nd prevent an edit war, we reached out
to the DWG, which did not solve the dispute. We now ask for opinions
Thank you in advance,
PS: The rules are formal enough that there exists a 1997 program
"Vlna" ("Tilde"), that can add nonbreakable spaces to TeX sou
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.
On 26 January 2018 at 16:11, marc marc <marc_marc_...@hotmail.com> wrote:
> Le 26. 01.
@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ý
@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
sformation rules in order to "decompress" it for
Stuff like "every road in this area is a 50km/h with source=cz:urban unless
On 13 January 2018 at 20:21, Stefan Nagy <stefan.n...@posteo.net> wrote:
example) added surface tags.
Maybe a wikidata tag?
On 14 January 2018 at 15:05, Matej Lieskovský <lieskovsky.ma...@gmail.com>
> Citation provided:
> Notice tha
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.
On 3 February 2018 at 06:56, Brad Neuhauser wrote:
> "Wild and Scenic River" is specifically
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.
PS: I am starting to suspect that we might need a wiki page concerning
Unicode usage in general (nbsp
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
Overpass... theoretically, it is doing exactly what it should be
doing. Somehow making it simpler to create a regex that does
(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
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
On 12 February 2018 at 22:28, Selfish Seahorse
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.
s more natural, but I do agree that it is far
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
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
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
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
Mail list logo