Re: [Tagging] Surface value for portuguese pavement

2018-01-14 Thread OSMDoudou
It would be a pity to not do justice to the artwork element in this sort of pavement. Not sure what to suggest however, but maybe something with artwork_type=mosaic ? [1] [1] https://taginfo.openstreetmap.org/tags/artwork_type=mosaic -Original Message- From: Fernando Trebien

Re: [Tagging] Surface value for portuguese pavement

2018-01-14 Thread Leon Karcher
I'm not sure about 'paving_stones'. This is rather for stones which are made of concrete. Maybe I missed some information, but those stones look very natural, what would make them a 'sett'. Am 15.01.2018 02:08 schrieb "Cez jod" : > Hi. > > I think that pawing stone will be ok.

Re: [Tagging] Surface value for portuguese pavement

2018-01-14 Thread Cez jod
Hi. I think that pawing stone will be ok. surface=paving_stone https://en.wikipedia.org/wiki/Permeable_paving#/media/File: Santarem_carfree.JPG Regars Slavo ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread André Pirard
On 2018-01-14 22:28, Mateusz Konieczny wrote: > On Sun, 14 Jan 2018 21:17:12 +0100 > André Pirard wrote: > >> access=no motor_vehicle=yes make much sense if that's the >> intention > This seems a poor idea, it will break everything that is not parsing > motor_vehicle

Re: [Tagging] Surface value for portuguese pavement

2018-01-14 Thread althio
I think they are much more flat, smooth than regular sett. I guess surface=paving_stones is a good option. -- althio On 14 January 2018 at 22:26, Mateusz Konieczny wrote: > On Sun, 14 Jan 2018 19:21:52 -0200 > Fernando Trebien wrote: > >>

Re: [Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread Mateusz Konieczny
On Sun, 14 Jan 2018 21:17:12 +0100 André Pirard wrote: > access=no motor_vehicle=yes make much sense if that's the > intention This seems a poor idea, it will break everything that is not parsing motor_vehicle (starting from a typical rendering).

Re: [Tagging] Surface value for portuguese pavement

2018-01-14 Thread Mateusz Konieczny
On Sun, 14 Jan 2018 19:21:52 -0200 Fernando Trebien wrote: > surface=cobblestone Rather surface=sett as stones at least look like flattened ones. Though adding smoothness is a a good idea given that surface=sett/cobblestone tagging is hopelessly messed up.

[Tagging] Surface value for portuguese pavement

2018-01-14 Thread Fernando Trebien
Hello, I'm wondering about what would be the best description for a Portuguese pavement [1] in OSM. They are quite common in Portuguese-speaking countries' sidewalks and pedestrian streets. I believe that should be surface=cobblestone due to the irregular cut of the stones, perhaps with

Re: [Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread André Pirard
On 2018-01-14 17:41, OSMDoudou wrote: > > Hello, > > > > Osmose is giving an error at many places around the R50 trunk with > reason "access=yes|permissive allow all transport modes" and > additional info "Including ski, horse, moped, hazmat and so on, unless > explicitly excluded". For example,

Re: [Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread Volker Schmidt
Please remove the access=yes it's not irrelevant, it's plain wrong. With the present tagging, e.g. horses appear to be allowed as they are not explicitly forbidden. > I also think that this type of errors is so unimportant that I also > > would not bother with fixing them and I would rather use

Re: [Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread marc marc
Le 14. 01. 18 à 19:09, Mateusz Konieczny a écrit : > On Sun, 14 Jan 2018 17:41:36 +0100 > "OSMDoudou" <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote: > >> Should I remove the entire "access" tag ? yes remove it, it's enought to add forbiden access like bicycle no footno highway

Re: [Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread Mateusz Konieczny
On Sun, 14 Jan 2018 17:41:36 +0100 "OSMDoudou" <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote: > Should I remove the entire "access" tag ? I am not convinced that access=yes adds anything on highway=trunk. I would not protest against removing it. I also think that this type of errors is

Re: [Tagging] area=yes on object without kind

2018-01-14 Thread OSMDoudou
Good point. Landcover seems to be the closest it can be. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] access=yes|permissive allow all transport modes

2018-01-14 Thread OSMDoudou
Hello, Osmose is giving an error at many places around the R50 trunk with reason "access=yes|permissive allow all transport modes" and additional info "Including ski, horse, moped, hazmat and so on, unless explicitly excluded". For example, this way [1] has the error [2]. The road is

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Stefan Nagy
Am 14.01.2018 16:01 schrieb Matej Lieskovský: 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

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Difference between lighthouses and beacons

2018-01-14 Thread Malcolm Herring
On 14/01/2018 13:47, Janko Mihelić wrote: So a fuzzy rule can be created, you can't have a man_made=lighthouse tag and seamark:xxx=yyy tags on the same object. That's instantly an error. Seamark tags are used for instruments that help navigation, and lighthouses are structures that can house

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Difference between lighthouses and beacons

2018-01-14 Thread marc marc
Le 14. 01. 18 à 14:47, Janko Mihelić a écrit : > a lighthouse can be an area with a seamark node at the place where > the light is. theoretically the difference seems correct to me. but if someone just wants to map a lighthouse, he'll do it with a simple node. you cannot require that anyone who

[Tagging] Difference between lighthouses and beacons

2018-01-14 Thread Janko Mihelić
A map with lighthouses was produced [1] that gained popularity because it was nicely rendered, but it showed how flawed OSM data was in this regard. Very often little beacons [2] are mapped as man_made=lighthouse, which is not right. Lighthouses are big structures that were built to have living

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Short-term parking zones

2018-01-14 Thread pbnoxious
Hello, I never thought about this before and it would open up a totally new way of tagging things. But I have some questions/comments: 1) How does this exactly work and do the usual applications expect this? E.g. would it work to add a tag to an otherwise untagged way that refers to a

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Stefan Nagy
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])

Re: [Tagging] Short-term parking zones

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

Re: [Tagging] Short-term parking zones

2018-01-14 Thread Stefan Nagy
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

Re: [Tagging] Short-term parking zones

2018-01-14 Thread pbnoxious
Hello, 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

Re: [Tagging] Water source types

2018-01-14 Thread Martin Koppenhoefer
sent from a phone > On 13. Jan 2018, at 01:56, Cez jod wrote: > > Maybe in 10 years we will have 10 tags responsible for water (3 for > drinking water > and 7 for non-drinking water plus subtags, etc.) . that makes sense?" > It is possible that I approach meny problems