Which too schemes? I think you'd need to be more specific.
As for deprecating semicolon-delimited lists. I don't think it's practical
to abolish them completely, so they'll have to stay.
I do agree that it makes sense to try and avoid them as much as possible,
but it's simply not always
On 22 January 2015 at 14:02, Dave F. dave...@madasafish.com wrote:
A shop that solely sells electronic cigarettes has been added locally. I
guess this type
of product will be on the increase so I think it's best to clarify unified
tag, if there's ever
been such a thing in OSM :-)
Yes, I
Hi Jo/Polyglot and list,
On 22 January 2015 at 12:01, Jo winfi...@gmail.com wrote:
Which too schemes? I think you'd need to be more specific.
1. key=values;separated;by;semicolon
2. several key:subkey=*
On Thu, Jan 22, 2015 at 12:59 PM, althio althio althio.fo...@gmail.com
wrote:
I even find the second example more difficult to visualize. It's just
worse
than the first in every respect.
From a mapper's point of view
My little +1 for key:subkey=*
New people don't know how to add new
2015-01-22 6:53 GMT+00:00 Marc Gemis marc.ge...@gmail.com:
It seems like the German community started some voting process on the
deprecation of the associatedStreet-relation (it was on the mailing list and
on the forum).
Discussion is going on on the wiki
Hi all - does anyone know what the geographic distribution of
associatedStreet is like? taginfo doesn't render a map (it seems it
doesn't do that for relations).
This shows a map, I don't know if this is what you are looking for:
http://taginfo.openstreetmap.org/tags/type=associatedStreet#map
Hi
A shop that solely sells electronic cigarettes has been added locally. I
guess this type of product will be on the increase so I think it's best
to clarify unified tag, if there's ever been such a thing in OSM :-)
Checking Tag-info it's 8/6 in favour of electronic_cigarettes over
On 21.01.2015 08:28, Markus Lindholm wrote:
Before we get carried away by a zillion relations I think we have to
answer the questions as to what purpose do we want to explicitly
associate an address with a POI or a building.
Is it so that the data consumer can find her way to a POI? That's
It's an actual example:
https://www.openstreetmap.org/node/80725474
https://delijn.be/nl/haltes/halte/303059 (real time information)
121 characters... there's still some breathing room. I guess the risk of
the street getting congested is higher than hitting the 255 characters
limit.
Jo
Hi Friedrich.
I can't say for whole World,
as for Russia we have plots of lands having addresses without buildings.
They are not always dedicated to be build up with something.
There is three ways, (maybe more, but i don't know for sure):
1. Large landuses as landuse=industrial may have their
Hi,
Am 22. Januar 2015 11:45:47 MEZ, schrieb althio althio althio.fo...@gmail.com:
Please vote here:
https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet
Is this a formal voting?
It is not as formal as a proposal voting. I would like to know how the
community (those who
On 22.01.2015 04:02, John F. Eldredge wrote:
If you have a strictly delimited plot of land, with no house currently
built upon it, but which is intended for later construction, does it have a
house number? Or is the address only assigned once a building is built?
When it is already intended
Rattling on about those bus stops, I have an other example:
https://www.openstreetmap.org/node/485938967
bus http://wiki.openstreetmap.org/wiki/Key:bus?uselang=en-US yes highway
http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stop
It is not as formal as a proposal voting. I would like to know how the
community (those who vote) think about associatedStreet relations. I think
that in Germany the majority does not like them (anymore).
I will announce a end date. This end date will be date of announcement of end
of
Please vote here:
https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet
Is this a formal voting?
Is there a date for start and end vote?
It looks strange, hidden on a Talk:page without the usual template or
RFC or call for votes on the international mailing lists.
althio
First point:
It is good that several people invent, propose and use various schemes.
Second point:
At some point, unification of schemes with similar intent would be great.
As usage grows, having the same kind of data treated differently is a pain
for everyone, mappers, developers, maintainers
On 22/01/2015, Andreas Goss andi...@t-online.de wrote:
Using - instead of _ goes against a very established tagging practice.
Only for whitespace as far as I know. So I don't see a issue here.
That surprises me, but looking at a dump of Ireland (taginfo search is
too coarse, so I used some
On 22 January 2015 at 18:00, fly lowfligh...@googlemail.com wrote:
Well the first page should be under proposal and it should not be listed
under shop or if only under some proposal paragraph
Only six shop types have been approved by the wiki/voting process:
bakery, baby_care, second_hand,
Am 22.01.2015 um 04:02 schrieb John F. Eldredge:
If you have a strictly delimited plot of land, with no house currently
built upon it, but which is intended for later construction, does it
have a house number? Or is the address only assigned once a building is
built?
In Germany the address
I even find the second example more difficult to visualize. It's just
worse
than the first in every respect.
From a mapper's point of view
My little +1 for key:subkey=*
In free text like this thread, several key:subkey=* may look more heavy and
complicated than
Existing pages: value e-cigarette is referenced in the wiki.
http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
http://wiki.openstreetmap.org/wiki/Key:shop#Others
The wiki page is very recent with only two contributors. I wouldn't be
surprised if e-cigarette in the db was also
Am 22.01.2015 um 18:08 schrieb Marc Gemis:
On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com
mailto:althio.fo...@gmail.com wrote:
Well at least iD knows quite well about the semi-colon:
Just merge two ways together and you might get access=no;yes
highway=primary;path without any
Good to have this discussion. From a computer expert point-of-view
relations are fantastic for data integrity and to keep database size low.
From an OSM point-of-view, which includes being friendly towards novice
users, relations should be avoided whenever possible. And associatedStreet
relations
Am 22.01.2015 um 19:43 schrieb Matthijs Melissen:
On 22 January 2015 at 18:00, fly lowfligh...@googlemail.com wrote:
Well the first page should be under proposal and it should not be listed
under shop or if only under some proposal paragraph
Only six shop types have been approved by the
Am 22.01.2015 um 21:32 schrieb Tod Fitch:
I've been following this and the addrN thread with a mixture of amusement and
irritation.
Lots of the arguments come down to how easy it is to parse using some tool or
another. Or whether the problem the original poster was trying to address
Existing pages: value e-cigarette is referenced in the wiki.
http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
http://wiki.openstreetmap.org/wiki/Key:shop#Others
On 22 January 2015 at 15:43, Dave F. dave...@madasafish.com wrote:
Ah, As normal cigarettes are sold in multiples I didn't
Volker Schmidt wrote:
I am very cautious about any of this kind of measurement for the following
reasons:
1) the results will be very difficult to standardise
2) the effort is far beyond that what a mapper can reasonably do.
Oh well, I guess I'll have to write a comment here, because I recently
Le 22/01/2015 14:00, althio a écrit :
Hi all - does anyone know what the geographic distribution of
associatedStreet is like? taginfo doesn't render a map (it seems it
doesn't do that for relations).
UK http://taginfo.openstreetmap.org.uk/tags/type=associatedStreet ~9000
PL
On Thu, Jan 15, 2015 at 7:13 AM, Kotya Karapetyan kotya.li...@gmail.com
wrote:
Dear all,
As of today, a total of 16 votes have been submitted, 11 of them are
approvals. Since 2 weeks have passed and the required number of votes
(15) has been reached, I have closed the voting and will proceed
opening_hours:Mo-We 08:00-17:00 = yes
opening_hours:Th-Fr 08:00-21:00 = yes
would in my opinion lead to an inordinate number of subkeys.
If you were reading other people messages you would probably notice
that opening_hours=* tag was mentioned as minor exception to general rule *not
to use
On 22/01/2015, fly lowfligh...@googlemail.com wrote:
The wiki page is very recent with only two contributors. I wouldn't be
surprised if e-cigarette in the db was also contributed by no more
than 1-2 mappers. I suggest contacting them to make sure that they are
ok with e_cigarette, and then
On Fri, Jan 16, 2015 at 4:03 PM, Kotya Karapetyan kotya.li...@gmail.com
wrote:
2. Having said this, I would like to draw your attention to the fact
that people who currently actively oppose the proposal have not
participated in a 4-month discussion, where most of the current
concerns were
Using a xxx:yyy schema also requires checkboxes besides every existing
value in JOSM presets. So I don't see how it is any easier for new mappers
or preset creators.
Problem in multiple values in value part in *key=value.*
How iD should parse cuisine=mexican;japanese?
This work repeated every
On Fri, Jan 16, 2015 at 4:03 PM, Kotya Karapetyan kotya.li...@gmail.com
wrote:
7. Personally, I believe drinking_water=* is a much better solution
than amenity=drinking_water:
7.1) The source of drinking water (which, I fully agree, is important
for a lot of users) may not be a dedicated
Propaganda. Propaganda. Propaganda.
But it's harder to get all tags in category. How would you get all the
payment methods, not the exact 'ellectrico'?
Why normal person need to know about all payments methods if he/she only
have mastercard/ellectrico/coins?
You probably never use data at all.
On 1/22/15 23:13 , fly wrote:
No, but it is common sence to introduce tags in proposal name space and
once they are in common use accept them because of it use.
Well, you can go ahead and create dozens of proposals that will go
nowhere. I have completely given up on that process. It will be
On Fri, Jan 23, 2015 at 12:22 AM, Никита acr...@gmail.com wrote:
we don't need to teach every person how to parse japanese from
cuisine=mexican;japanese
using f#$% regexes
In my code editor I can search for complete word by ticking a checkbox,
how simple is that ? It will not match
On 15-01-22 01:44 PM, tagging-requ...@openstreetmap.org wrote:
Message: 3
Date: Thu, 22 Jan 2015 18:08:49 +0100
From: Marc Gemis marc.ge...@gmail.com
To: Tag discussion, strategy and related tools
tagging@openstreetmap.org
Subject: Re: [Tagging] Wiki Edit War on using/avoiding
A) For which keys and/or type of data are semicolon lists pertinent?
For keys that can logically have multiple values and that are not the
main/defining key of the object.
B) How can semicolon lists be handled better in the different editors?
If you are using a tag from a preset, iD theorically
Using - instead of _ goes against a very established tagging practice.
Only for whitespace as far as I know. So I don't see a issue here. I
would even say using _ is wrong.
e_cigarette = e cigarette
e-cigarette = e-cigarette
The wiki page is very recent with only two contributors. I
On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com wrote:
New people can have problems or make mistakes and then experienced
users can help and point to recommended tagging or explain good
practices .
Not everybody reaches out to community for help. Probably many just stop
On 22/01/2015 15:22, moltonel 3x Combo wrote:
On 22/01/2015, althio althio.fo...@gmail.com wrote:
Existing pages: value e-cigarette is referenced in the wiki.
http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
http://wiki.openstreetmap.org/wiki/Key:shop#Others
Using - instead of _ goes
a minor issue with semicolon separated lists: we don't have yet defined how to
escape actual semicolons in values.
cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Am 22.01.2015 um 14:07 schrieb Jo winfi...@gmail.com:
network DLVB;IBXL;TECB;TECC;IBXL
operator De Lijn;STIB/MIVB;TEC;STIB/MIVB
I'd completely refrain in this case from tagging these to one object and use
relations instead.
I cannot understand your example without illustration.
Hide the internals from the end-users.
We can easily hide
*something*:japanese=yes
*something*:korean=yes
under single field *something*=*traditional semicolon presentation*, but
not vice versa. I suggested plugin for JOSM that will present
45 matches
Mail list logo
