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
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
@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:
>
@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
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
@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
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
(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
defaults?
Matej Lieskovský
On 12 February 2018 at 22:28, Selfish Seahorse
wrote:
>>
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
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
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
" 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
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
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
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
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
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
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
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
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
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
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
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
)
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
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:
>
>
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
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
+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
29 matches
Mail list logo
