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 differently and I do
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 a
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 conceptua
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, leaving
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])
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 of
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 relati
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
( https://www.openstreetmap.org/relation/49715 for e
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
qua
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
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
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 th
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 mysel
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 s
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 clearl
Good point. Landcover seems to be the closest it can be.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
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
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
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 m
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,
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 smoothness
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.
_
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).
__
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:
>
>> surface=cobblestone
>
> Rather surface=sett as stones at
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 (starting from a typical ren
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
https://lists.openstreetmap.org/listinfo/tag
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.
> surface=paving_st
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 [mailto:fe
28 matches
Mail list logo
