On 5 June 2015 at 12:36, Martin Koppenhoefer dieterdre...@gmail.com wrote:
Am 05.06.2015 um 11:33 schrieb David Fisher djfishe...@gmail.com:
As for landuse=residential -- I agree that we could probably do
without it. But it does add to the readability of the map, especially
at low
You are fond of proposing keys with arbitrary numbers as the value, or part
of the value. This would be fine if we were using a relational database,
where a mapper could select one of a list of human-language descriptions,
which would then get translated to the magic number for storage.
The problem with oneway is the key name - it's 3 letters too long:
How is this NOT trolling?
--
View this message in context:
http://gis.19327.n5.nabble.com/OSM-is-a-right-mess-was-Craigslist-OpenStreetMap-Rendering-Issue-tp5846860p5847385.html
Sent from the Tagging mailing list archive at
In the same vein:
way=0: no way!
Better not to lose sleep over 3 letters.
Jo
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On 5 June 2015 at 10:33, David Fisher djfishe...@gmail.com wrote:
On Fri, Jun 5, 2015 at 12:33 AM, pmailkeey . pmailk...@googlemail.com
wrote:
The issue with the 'oneway' key is that the key itself contains 'data'
relating to the value. Oneway without a value would imply =yes whereas
Sent from my iPhone
On Jun 7, 2015, at 9:26 AM, John Eldredge j...@jfeldredge.com wrote:
presenting a mapper with a list of choices such as photo1, photo2, and photo3
is likely to result in corrupted data, due to a mapper picking one at random,
Remember the epic discussion on track type?
On 6/7/15 00:39 , jgpacker wrote:
The problem with oneway is the key name - it's 3 letters too long:
How is this NOT trolling?
Honestly at this point I'm not sure either anymore. I just know it's
getting annyoing as fuck...
__
openstreetmap.org/user/AndiG88
On Jun 5, 2015, at 8:26 AM, pmailkeey . pmailk...@googlemail.com wrote:
I'm not a fan at all of non-physical road descriptions like primary, tertiary
etc.
Japan completely breaks OSM road descriptions, and uses the classifications
above tertiary to match their governmental classification
On Fri, Jun 5, 2015 at 12:33 AM, pmailkeey . pmailk...@googlemail.com wrote:
On 4 June 2015 at 10:46, David Fisher djfishe...@gmail.com wrote:
On 04/06/15 00:48, pmailkeey . wrote:
A value of residential here seems to need a key to identify whether it
relates to a building or landuse.
Am 05.06.2015 um 11:33 schrieb David Fisher djfishe...@gmail.com:
As for landuse=residential -- I agree that we could probably do
without it. But it does add to the readability of the map, especially
at low zoom levels, as it enables you to see at a glance where places
are and how big
On 4/06/2015 11:49 PM, Andreas Goss wrote:
OK, next option is
directions=1 (way)
directions=2
directions=unknown.
That way, the key has no built-in value itself forcing the value to be
read to have any, well, value !
And someone reading that tag will have no idea what it stands for.
Maybe
On 5/06/2015 9:33 AM, pmailkeey . wrote:
The issue with the 'oneway' key is that the key itself contains 'data'
relating to the value. Oneway without a value would imply =yes whereas
building without a value (or =yes) would give data independent of the
value, IYSWIM
building=
hospital=
For me it stands for 1 or 2 persons standing there you can get directions
from. All you need to do is ask. It might be unknown when they're there :-)
Anyway, for all its flaws the tagging system mostly works, don't fix it if
it isn't (completely) broken.
Cheers,
Jo
2015-06-05 0:59 GMT+02:00
On 5 June 2015 at 00:13, Jo winfi...@gmail.com wrote:
For me it stands for 1 or 2 persons standing there you can get directions
from. All you need to do is ask. It might be unknown when they're there :-)
Anyway, for all its flaws the tagging system mostly works, don't fix it if
it isn't
On 4 June 2015 at 14:49, Andreas Goss andi...@t-online.de wrote:
OK, next option is
directions=1 (way)
directions=2
directions=unknown.
That way, the key has no built-in value itself forcing the value to be
read to have any, well, value !
And someone reading that tag will have no idea
On 4 June 2015 at 10:46, David Fisher djfishe...@gmail.com wrote:
On 04/06/15 00:48, pmailkeey . wrote:
A value of residential here seems to need a key to identify whether it
relates to a building or landuse. However, you suggest
building=residential as possibly being redundant. In fact,
On 4 June 2015 at 08:28, AYTOUN RALPH ralph.ayt...@ntlworld.com wrote:
highway=road is where you cannot determine anything other than it is some
link between features.
Then you have not been trying to find routes between villages in Africa or
Nepal during a HOT Activation where the
OK, next option is
directions=1 (way)
directions=2
directions=unknown.
That way, the key has no built-in value itself forcing the value to be
read to have any, well, value !
And someone reading that tag will have no idea what it stands for. Maybe
those are different exits? Does it has
[Errr road is where you cannot determine the classification.
highway=road is where you cannot determine anything other than it is some
link between features.
[ From satellite imagery I can infer the surface and number of lanes
most of the time.
[ I can usually infer the
On 04/06/15 00:48, pmailkeey . wrote:
A value of residential here seems to need a key to identify whether it
relates to a building or landuse. However, you suggest
building=residential as possibly being redundant. In fact, I'd turn this
on its head and make landuse=residential (with the
On 3 June 2015 at 02:51, Andreas Goss andi...@t-online.de wrote:
No tag
Tag oneway
tag twoway
not an'equals' in sight and difficult to mistake twoway for oneway.
I would say that's much worse both for mappers as well as consumers. Not
even to mention documentation, because now you have
On 3/06/2015 11:16 PM, Martin Koppenhoefer wrote:
Am 03.06.2015 um 13:48 schrieb Richard ricoz@gmail.com:
Better ideas?
there's highway=road in use for situations where you trace from aerial imagery
and have no clue about the situation on the ground (name, oneway, maxspeed etc)
On Tue, Jun 02, 2015 at 07:28:11PM -0500, John Eldredge wrote:
The reason for tag/value pairs such as oneway=no is that the absence of a
oneway tag can mean either that it is unknown whether a given way is one-way
or not, or that it is definitely known to be not be one-way. Using
one-way=no
On Wed, Jun 03, 2015 at 12:44:13PM +0200, Martin Koppenhoefer wrote:
Am 03.06.2015 um 12:18 schrieb Richard ricoz@gmail.com:
oneway=uknown
for the cases where soemone is not sure? Without a possibility to express
that possibility armchair mappers can either stop mapping
If oneway=unknown is not present then it already is implicitly there. Too
many tags showing that something is unknown may not be needed.
On Wed, Jun 3, 2015, 6:49 AM Richard ricoz@gmail.com wrote:
On Wed, Jun 03, 2015 at 12:44:13PM +0200, Martin Koppenhoefer wrote:
Am 03.06.2015
Am 03.06.2015 um 12:18 schrieb Richard ricoz@gmail.com:
oneway=uknown
for the cases where soemone is not sure? Without a possibility to express
that possibility armchair mappers can either stop mapping roads they dont
know or make a mess of the data.
armchair mappers without
Am 03.06.2015 um 13:48 schrieb Richard ricoz@gmail.com:
Better ideas?
there's highway=road in use for situations where you trace from aerial imagery
and have no clue about the situation on the ground (name, oneway, maxspeed etc)
cheers,
Martin
The reason for tag/value pairs such as oneway=no is that the absence of a
oneway tag can mean either that it is unknown whether a given way is
one-way or not, or that it is definitely known to be not be one-way. Using
one-way=no states that it is definitely known not to be one-way.
--
John F.
iD shows oneway=unknown if it's not set. If it's unknown, iD should not
show oneway at all.
In OSM if oneway=no then it's not oneway and the oneway tag should not
appear at all.
The only time oneway should appear is in the case of oneway=yes - and the
'=yes' is superfluous.
OSM's k=v design is
On 3 June 2015 at 01:23, Warin 61sundow...@gmail.com wrote:
MOST use OSM. 90% will be out there adding things. Only a few join here to
add tags, and fewer still try to improve the structure.
That is quite possibly one of the big issues with it. And TBH, it's such a
shame. More regulated
On 3/06/2015 10:39 AM, pmailkeey . wrote:
On 3 June 2015 at 01:23, Warin 61sundow...@gmail.com
mailto:61sundow...@gmail.com wrote:
MOST use OSM. 90% will be out there adding things. Only a few join
here to add tags, and fewer still try to improve the structure.
That is quite
On 3 June 2015 at 01:28, John Eldredge j...@jfeldredge.com wrote:
The reason for tag/value pairs such as oneway=no is that the absence of
a oneway tag can mean either that it is unknown whether a given way is
one-way or not, or that it is definitely known to be not be one-way. Using
No tag
Tag oneway
tag twoway
not an'equals' in sight and difficult to mistake twoway for oneway.
I would say that's much worse both for mappers as well as consumers. Not
even to mention documentation, because now you have two wiki pages which
again is always a good source for errors.
As a
33 matches
Mail list logo
