from:"Peter"


Hi

some months ago I started a craft= proposal in my wiki user space:
http://wiki.openstreetmap.org/wiki/User:MaZderMind/Key:craft
http://wiki.openstreetmap.org/wiki/User:MaZderMind/DE:Key:craft

It has grown over time and I got some questions to move it over to map 
features. I'd love to do so and I will also create a JOSM preset for 
that new key.


I'd just wanted to ask here if this would be ok for you, too.

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 24.08.2010 10:27, schrieb Tom Chance:


You are of course welcome to begin the proposal process, follow these
instructions here:
http://wiki.openstreetmap.org/wiki/Creating_a_proposal

Okay, I'll do so.


You will need to create this as a proper proposal page, invite some more
discussion and then take it to a vote. If successful, you can then move
it into the map features page.
It is common to post this proposal to this list and not to talk@ and 
such, right?



I have added some comments on the discussion page, I think it needs more
work before going to a vote.

I don't really like discussion on the wiki, so I'll quote and answer here

 == When is a craft a trade? ==
 The above suggestion relating to bicycle shops, most of which offer
 both new bikes and repair services, illustrates that it isn't always
 easy to say when to use craft or shop. A lot of the values you have
 given overlap with shop values, for example a bakery, butcher,
 computer shop, gardening, hairdresser, optician and shoes. If this
 proposal is to work I think you need to take a lot of those values
 out and more clearly (1) why and (2) how you make this distinction.
 TomChance 09:25, 24 August 2010 (BST)

A lot of the values have not been added by me and I see this problem, 
too, but did you read the distinction on the proposal page? It goes like


A place producing or processing customised goods. To differentiate 
between trade, service and craft. This proposal wants to reserve shop=* 
for trade (focused on selling pre produced goods) and creates craft=* 
for small production on demand and by order. Unlike man_made=works the 
goods are often customized to the customers' needs and specially 
produced for them.


So, the bike shop is not producing bikes, so it's shop=bicycle with eg. 
service=repair. but service=* is yet another proposal..


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 24.08.2010 10:28, schrieb Alan Mintz:

At 2010-08-24 01:08, =?ISO-8859-15?Q?Peter_K=F6rner?= wrote:

some months ago I started a craft= proposal in my wiki user space:
http://wiki.openstreetmap.org/wiki/User:MaZderMind/Key:craft


My observations:

- plummer should be plumber
- Is heating_engineer really different from hvac?
- I would suggest glass instead of glaziery - the latter sounds like
someplace that glazes things (regardless of the definition)
- gardening should be gardener in keeping with the other values that are
named for the craftsman, not the craft


I'm not a native speaker so I'll take your hints as they come. Regarding 
the difference between heating_engineer and hvac I'm not sure, too, but 
I know crafts that only installs air conditioner but not heater. They 
usually specialized on big cooling installations in food production or 
transport. I'd suggest to keep them seperated.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 24.08.2010 12:17, schrieb Liz:

the butcher and baker are working with raw materials, producing something
temporary and not required to have beauty in its form
What, there is no beauty in my rump steak? I cant accept that, it's not 
true!!!1eleven11! ;)


Just kidding.

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 24.08.2010 13:38, schrieb Elena of Valhalla:

On 8/24/10, Peter Körnerosm-li...@mazdermind.de  wrote:

Am 24.08.2010 12:17, schrieb Liz:

the butcher and baker are working with raw materials, producing something
temporary and not required to have beauty in its form

What, there is no beauty in my rump steak? I cant accept that, it's not
true!!!1eleven11! ;)


you're kidding, but what about a (real) sushi chef who produces
something temporary, but is also required to give extreme care to the
estetics of the dish?



I think we should stick with the general classification a sushi 
restaurant and ignore the specialty a specific sushi chef when 
dealing with tagging. As Emilie Laffray said, beauty is in the eye of 
the beholder and so it can't be part of our definition for craft=.


I'd like Élisée Reclus proposal better: if it sells something to end 
customers is a shop and not a craft.


What do you think about that?

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 24.08.2010 14:37, schrieb Élisée Reclus:

Am 24.08.2010 14:28, schrieb Simone Saviolo:

2010/8/24 Peter Körnerosm-li...@mazdermind.de:

I'd like Élisée Reclus proposal better: if it sells something to end
customers is a shop and not a craft.


A sculptor (and an art gallery, often) ultimately hopes to sell his
artwork. By that criterion, nothing would be cratfsmanship.


Everyone knows what a shop or store is.  Some we could write use shop=*
for shops or something.  We don't need perfect definitions.


Why does the list of proposed values for craft= then contain butcher and 
bakery? I don't see them as a craft but I hesitate to remove them just 
because of a feeling that's not based on a well formed definition.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 24.08.2010 15:07, schrieb Pieren:

On Tue, Aug 24, 2010 at 2:39 PM, Peter Körner osm-li...@mazdermind.de
mailto:osm-li...@mazdermind.de wrote:

Why does the list of proposed values for craft= then contain butcher
and bakery?


Remove the obvious shop  entries like bakery and butcher
I did so and also added a sentence about the dual use of shop= and 
craft=. I'll convert the page to a proposal this evening and immediately 
go to Proposed stage.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Craft


Hi all

I announced the unofficial proposal on this list already. I moved it 
into the regular proposal cycle by creating a proposal-page for


Craft - A place producing or processing customized goods
  http://wiki.openstreetmap.org/wiki/Proposed_features/Craft

Please comment - here or on the Discussion Page..

Peter


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 25.08.2010 01:12, schrieb M∡rtin Koppenhoefer:

2010/8/24 Peter Körnerosm-li...@mazdermind.de:

- Is heating_engineer really different from hvac?



heating_engineer is not a craft but an engineer. The craft is hvac or
plumper. A company that installs AC is not necessary equipped with an
engineer. Basically the engineer does the calculation and the workers
do the installation. THey do not have to work in the same company.


Looking a little deeper [1], the type of craft I was talking about was 
used in Germany but it got included in a greater superset of jobs [2] 
that sound very like hvac. So I'll remove heating_engineer from the 
list. It may be well added as


service=engineer_agency
engineer=heating

this is just a sample and for a sevice proposal we need to think a 
little more about re-purposing the service-tag, but maybe that's stuff 
for another thread.


Peter


[1] http://de.wikipedia.org/wiki/Heizungsbauer
[2] 
http://de.wikipedia.org/wiki/Anlagenmechaniker_f%C3%BCr_Sanit%C3%A4r-,_Heizungs-_und_Klimatechnik


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 25.08.2010 01:14, schrieb M∡rtin Koppenhoefer:

2010/8/24 Élisée Reclusfe-nospam-2009-03...@arcor.de:

Am 24.08.2010 10:08, schrieb Peter Körner:

http://wiki.openstreetmap.org/wiki/User:MaZderMind/Key:craft
http://wiki.openstreetmap.org/wiki/User:MaZderMind/DE:Key:craft


Are artists, computer experts, fashion designers, funeral directors and
photographers really craftsmen?

There could also be a service=* with service=tax_advisor etc.


+1, also look at the new tag office


Yes, that's pretty cool. With shop, craft and office we got all three 
types of business. Well done!


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 25.08.2010 01:34, schrieb M∡rtin Koppenhoefer:

Maybe you wanted to express handicraft (de:Kunsthandwerk)?


Most of the values were copied from the german proposal page and have 
thus not been written or reviewed from native speakers. I exchanged art 
with handicraft in the examples list.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 25.08.2010 03:53, schrieb M∡rtin Koppenhoefer:

2010/8/25 John F. Eldredgej...@jfeldredge.com:

Food delivery and meals on wheels both imply that the food is brought to the 
customers.  I am talking about an establishment in a fixed location, having a kitchen but little or no 
provision for customers to eat on the premises.  The customers are expected to take the food with them and 
consume it elsewhere.  A fast-food establishment with a drive-in window, but no dining space, would be one 
example; another would be what is sometimes termed a cook-shop, a small restaurant operating out 
of a storefront location, dealing with walk-up customers, but without space for a table for customers to use.


the will IMHO generally not be restaurants but fast_food.


maybe with extra takeaway=yes and drivein=yes :)

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 25.08.2010 15:32, schrieb John F. Eldredge:

Most examples of an establishment having a kitchen, but no provision for 
customers to eat on the premises, would fall under the fast-food category, but 
not all.

This is highly dependent on how you define fast-food.

 For example..
I'd regard this as fast-food - grab and take away - no matter what kind 
of food is sold.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] craft= Proposal


Am 25.08.2010 17:40, schrieb John F. Eldredge:

This was in reaction to a statement made, earlier in the discussion, that said 
(more or less) that an establishment that cooked and sold food had to have 
customer seating in order to be classified as a restaurant.
I think this has been prooved wrong. If you can eat there it is a 
restaurant or a fast_food but not a craft. If this conclusion is right, 
then let's stop here and keep the discussion tight to the craft tag.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] sidewalks

2010-08-26 Thread Peter Wendorff


 Hi.
I'm new to this list, so at first let me introduce myself in a few words.
I'm Peter and a student in computer science at the university of 
Paderborn, Germany.
Currently I write my bachelor thesis about navigation for the blind 
based on OpenStreetmap data.
In that context I try to figure out how the openstreetmap database is 
useful to give navigational instructions for blind and visually impaired 
people.


Therefore I tagged the campus of my university in more detail, adding 
every sidewalk as dedicated geometry to the streets.


But at the moment there are two problems:
1) naming
2) distinction between sidewalks and other footways

Everything I find to that topic in the wiki is dealing with the more or 
less complex lane topic I would like to avoid for easier tagging.


My approach would be - and I would like to get your opinions on that:
- a sidewalk is tagged like every other footway
   highway=footway|path
   (foot=yes)
   (segregated=yes|no)
   footway=sidewalk
   name=NAME-OF-STREET

contra arguments:
- renderers possibly render more than one name for one street. To solve 
that a simple rule could be added to the rendering styles to avoid 
naming of footway=sidewalk.

- a little bit error prone as redundant with name tags.

Pro arguments from my point of view:
- no geometric analysis necessary (finding parallel streets to unnamed 
footways)
- simple to apply even without deeper knowledge of editors; could even 
be given as training task for new mappers ;)
- existance of footways in the editor is obvious (in contrary to tagging 
sidewalks as tags at the street)


Why not model sidewalks as lanes:
1) sidewalks and footways build a widely separated, dedicated network of 
ways; that's a difference to lanes at the driveway
2) dedicated sidewalks make it a lot more simple to tag crossing details 
like islands etc.


awaiting your comments

Peter

P.S.: No, i didn't wrote a proposal for that yet, but will do if it's 
confirmed to be a good idea or to be able to become a good idea ;)


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sidewalks

2010-08-26 Thread Peter Wendorff


 Hi David.
Thanks for your reply - I'll comment your (shortened) mail in between.

On 26.08.2010 22:47, David ``Smith'' wrote:

On Thu, Aug 26, 2010 at 4:25 PM, Peter Wendorff
wendo...@uni-paderborn.de  wrote:
Makes sense to me.  You might consider one minor modification, though:
maybe we could add a couple of disambiguation words to the name for
sidewalks.  For example, an east-west street called Drury Lane might
have sidewalks called Drury Lane North Sidewalk and Drury Lane South
Sidewalk.  This disambiguates the sidewalks from the street and from
each other.
Well... if a sidewalk has a dedicated name I would have mapped it as 
separate way without tagging it as a sidewalk, as it's another way by name.
Adding south north etc. to sidewalks is not a good idea. If an 
application needs this data, it has to get the geometric relation 
between sidewalk and street to add north/south/west/east or - if 
preferred left/right (depending on the walking direction).

Some other points that may well have already crossed your mind:

* If a street has its sidewalks mapped separately, the street itself
should probably be tagged with foot=no.

That's possible and should be recommended, yes.

* This provides an opportunity to characterize each sidewalk/street
crossing (crosswalk).  On the node where they intersect, tags could be
used to indicate whether there is a dedicated crosswalk signal tied to
the traffic signal, or if the traffic signal implicitly governs the
crosswalk too, or if there is no such signal.  There can be tagging
for audible signals.  Of course, if there simply is no crosswalk on
that side of the intersection, then the sidewalk shouldn't be mapped
between the two corners concerned.  This information can be extremely
useful to navigation for the blind.

;) I know.
I tag crossings as a line of 5(!) nodes - let's call them A,B,C,B,A.
C is the node shared between street and crossing footway. it's tagged as
highway=crossing
crossing=unmarked|uncontrolled|traffic_signals
crossing_ref=zebra|pelican... if one fits

if crossing=traffic_signals is applied, additional tags are:
traffic_signals:sound=yes|no|locate|walk
traffic_signals:vibration=yes|no
traffic_signals:arrow=yes|no
traffic_signals:minimap=yes|no
button_operated=yes|no

The nodes B describe the border between sidewalk and street. Thus they 
are tagged as

sloped_curb=0|low|normal|high|*
where * can be an arbitrary height in metric dimension. The numbering 
scheme is proposed by the wheelchair-routing people, because wheelchair 
users need to know the exact height of the curb to decide wether they 
can drive up/down there. For blind people the reduced tagging scheme is 
enough and that's easy for the mappers as it's possible to collect these 
data without measuring (even from the bus).

tactile_paving=yes|no|primitive
primitive is applied where there is a tactile paving, but not made of 
THE tactile paving stones. Often small cobblestones are used instead.


The A nodes are the connectors to the sidewalks on both sides of the 
crossing.
It's not correct to merge A and B node to one node, because that could 
lead to a tactile paving not connected to the specific crossing.


I hope, I didn't forget parts of the crossing tagging I apply currently ;)

* Instructions generated by a blind-navigation program, particularly
when based on data with streets and sidewalks separated, should almost
certainly include instructions like Cross Drury Lane.
Yes, exactly - and therefore explicit tagged crossings are necessary. 
Crossing a street is really dangerous in most cases for blind people.
Being able to get best crossing places at the street is the one and only 
solution to get best possible security at that point.


If you want, look at the streets and crossings I mapped here. Most 
footways should be tagged no (the sidewalk scheme is not applied yet, 
sidewalks are unnamed there). Link: 
http://www.openstreetmap.org/?lat=51.70693lon=8.76567zoom=16layers=M
Note: the footways often are not visible because they are hidden by the 
streets. I tried to locate footways in a distance to the streets as they 
are (street.width/2+sidewalk.width/2), but streets are rendered wider 
than they are in most cases.


regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sidewalks

2010-08-26 Thread Peter Wendorff


 Hi Tobias.

On 26.08.2010 23:52, Tobias Knerr wrote:

On 26.08.2010 22:25, Peter Wendorff wrote:

My approach would be - and I would like to get your opinions on that:
- a sidewalk is tagged like every other footway
highway=footway|path
(foot=yes)
(segregated=yes|no)
footway=sidewalk
name=NAME-OF-STREET

I understand why you like this approach: The mappers will essentially
draw the routing graph for you. ;-)

Well - yes, that's a good aspect, too - but not the only one.

Generally, individual ways for sidewalks and cycleways make it easier to
use the data for navigation, while adding tags (or relations) to the
roads themselves appears somewhat easier for renderers.

that depends...

I happen to write a (3D) renderer at the moment, so I assume this will
create some challenges for me. Simply drawing the footways and roads
independently will certainly look bad - there will either be gaps
between the sidewalk and the road or they will overlap. Unless, of
course, the distance between the sidewalk way and the road way is
exactly half the sum of their respective width tags' values ... which is
unlikely, to say the least. *g*
That's true, yes. I would like to add one (but not sure what is the 
best) of the multilane-proposals - perhaps even the area proposal to it, 
but that should be compatible AFAIK. If applied, you could decide wether 
to render sidewalks separately or with a different implementation from 
the informations you get via the relations.


Only using the relations I fear your problem is not solved, too:
Consider a street where at the side is a sidewalk, and in between 
constantly changing a strip of grass, parking line, both of them, nothing.

How would you render that only using tags or relations?
I think there are issues where simply using the relations will fail, too.

So I will need to associate sidewalks with road sections. And therefore


- no geometric analysis necessary (finding parallel streets to unnamed
footways)

... I *will* need to do geometric analysis.
I agree - but did you think you can write a RENDERER without doing 
geometry? :D

It's still possible, though (or so I hope, at least...), so your
proposed solution would be acceptable for me. It's actually nice that it
works well with today's editors, while other approaches require editor
or even API improvements. This will probably lead to fast adoption by
mappers.


2) dedicated sidewalks make it a lot more simple to tag crossing details
like islands etc.

Could you describe crossing layouts in more detail? I assume you would
model them like this

A  B  C

|  |  |
|  |  |
*--o--*
|  |  |
|  |  |

where A and C are sidewalks, B is a road, and *o are junction nodes.
If we use the existing tagging for crossings, then node o should be
tagged highway=crossing + crossing=island/...

except of that I prefer to explicitly tag crossings, yes.

So how would you tag the horizontal way? May I suggest that it is tagged
differently from A and C to make it easier to distinguish in software?
Currently I don't tag it differently. It's a footway/path as the 
sidewalks are, too.
I use to add sloped_curb and tactile_paving to every crossing, but you 
are right - that should be optional perhaps.
Applying sloped_curb and tactile_paving allows me to identify the way 
you propose to tag different  as the way between sloped-curb and 
sloped-curb with highway=crossing on the node(s) in between.

But you are totally right.

Any ideas how to call the crossing-way?
Highway=crossing is ambiguous with the crossing node itself and 
therefore I would like to find another tag here.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sidewalks

2010-08-27 Thread Peter Wendorff



On 27.08.2010 08:06, lkyto...@cc.hut.fi wrote:

contra arguments:
- renderers possibly render more than one name for one street. To 
solve that


It's not (only) a rendering issue. The name of the road is
Foo street, but the sidewalk doesn't have a name of its
own; it shouldn't be named.
As the sidewalk is defined as part of the street, not another way, it is 
named in my interpretation.

Your argument counts, if you say the same for the street itself.
To be precise we would have to set no name to the street, too and add 
some kind of relation carrying the name.


As that's difficult to do I would prefer to be a little bit unprecise in 
the other direction, naming sidewalk and street the same.


I'm not generally against that argument - I give it equally weight to my 
opinion at current. I would prefer to get mor opinions ;)

If people feel it's necessary to tie it to a specific nearby
way, go for some other tag; sidewalk_of=Foo street ? 

This alternative has two drawbacks leading me to prefer my variant:
- sidewalk_of is a new tag with has to be known by mappers.
- I don't see, where it's more powerful than just naming the footway + 
setting it as sidewalk

Some have
proposed relations for making up whole streets, but it hasn't
gained much use with house numbering - most use the tag
addr:street - so I doubt it would happen with sidewalks, either.

That's the reason for my idea not to use a relation, yes.

regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sidewalks

2010-08-27 Thread Peter Wendorff

Hi.

On 27.08.2010 11:36, Nathan Edgars II wrote:

One would think that a router would be able to prefer a parallel
footway without a special tag.

One real problem with routing along
sidewalks is that they sometimes don't have curb cuts at
intersections, yet it's legal to cross there. Example:
http://maps.google.com/maps?ll=28.457321,-81.45624spn=0.000993,0.002575t=kz=20layer=ccbll=28.457407,-81.45623panoid=W8rLGRkFUgFWzRRpWLSWCgcbp=12,59.26,,0,10.44
To route correctly here, you'd either have to draw an incorrect
footway, or the router would need to be able to jump a gap if
there's no barrier (and you don't tell it you're in a wheelchair).
Hmm... Where there are strips of grass between street and sidewalk I
didn't draw a crossing yet, as usually there is a more secure crossing a
few meters away (e.g. traffic signals or zebra crossing).
In Germany I think there would be a crossing somewhere on the next
kilometer aside - and to get the most secure route it should be advised
to use that.

To make clear:
using crossings only is not a must - that's right.
But often the most secure route is required - for blind people or even
for children. To fit this requirement an application should be able to
decide where a crossing is most secure,

Impossible, where not given in the data.
If the router has to guess crossings, there will even be routes across
big streets outside of cities.

In any case:
- it's not possible to guess reliable for crossings by software without
support from the data

- it's not a good option to ignore tagged crossings.

regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Semicolons? (was Re: RFC: generator:* (for power=generator features))

2010-08-27 Thread Peter Wendorff


 On 27.08.2010 11:37, Nathan Edgars II wrote:

On Fri, Aug 27, 2010 at 5:07 AM, Tom Chancet...@acrewoods.net  wrote:

I have been told two different things, now. Do we use semicolons or not?

I have been contributing to OSM for five years and have never used
semicolons, so I am inclined to go with your proposal.

I've come across at least one situation where a semicolon is
necessary: the same node is a highway=traffic_signals and
highway=motorway_junction.

I know of
highway=crossing with crossing=island;traffic_signals

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Sauna

2010-08-27 Thread Peter Körner


Hi Kim,

why exactly do you want to convert a widely used tag (amenity=sauna, 
~1000 uses) to a very rarely used tag (leisure=sauna, ~13 uses).


The Proposal does not tell why this change is required.

Peter


Am 27.08.2010 14:31, schrieb Kim Slotte:

Hello,

There is plans to replace amenity=sauna with leisure=sauna. Also usage
access in combination is proposed.

Feel free to discuss about the map feature at:
http://wiki.openstreetmap.org/wiki/Proposed_features/Sauna

Br, Kim S

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How do you map handicapped parking? (and other questions)

2010-08-29 Thread Peter Wendorff


 On 29.08.2010 07:04, Nathan Edgars II wrote:

There doesn't seem to be a tag on the wiki for either handicapped
parking spots in a larger lot or a dedicated handicapped lot.

use capacity:disabled=n for that.

If these slots are at a specific place inside a bigger area, tag it 
additionally there.
To place more details you can tag each lot dedicated as amenity=parking, 
collect everything by landuse=parking and 
highway=service/service=parking_aisle.

Is building=pavilion correct for a roof with no walls?
I think, we need a little bit more details to buildings as balconys 
could be tagged also.

Is there a way to distinguish an older gnarly tree suitable for
climbing from a recently-planted tree?

suitable for climbing is difficult ;)
I would point to
height=* - what could be a way to estimate the stability, too :D

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway direction


 On 31.08.2010 20:58, David Earl wrote:

Just to throw something else into this discussion...
  highway=steps
It doesn't (or at least, isn't documented as) have direction, but 
_could_ have in the same way as rivers (direction of way is down the 
steps, say).

To quote the wiki: (http://wiki.openstreetmap.org/wiki/Steps)
Discussion 
http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dsteps whether 
the *direction of the way* should point up- or downhill is so far been 
inconclusive. It's possible to tag this explicitly using incline 
http://wiki.openstreetmap.org/wiki/Key:incline=up 
http://wiki.openstreetmap.org/wiki/Tag:incline%3Dup or incline 
http://wiki.openstreetmap.org/wiki/Key:incline=down 
http://wiki.openstreetmap.org/wiki/Tag:incline%3Ddown. An alternative 
unofficial way has been to use direction 
http://wiki.openstreetmap.org/wiki/Key:direction=up 
http://wiki.openstreetmap.org/wiki/Tag:direction%3Dup or direction 
http://wiki.openstreetmap.org/wiki/Key:direction=down 
http://wiki.openstreetmap.org/wiki/Tag:direction%3Ddown, which are 
equivalent to the incline tags.


I think, incline and direction are both accepted and widely used; I 
often tag both to make it useful to as much applications as possible.
But there is nothing like steps are always drawn in direction from low 
to high - at least that's not documented.
Some other things that might have natural flow or directionality: 
cable cars, ski runs, power lines, pipelines, slipway, pier, military 
range, racecourse, athletics track


Incidentally, direction of flow for waterway=canal doesn't work on the 
summits and troughs of a locked canal, but that's probably being 
pedantic.


Coastline and boundaries most definitely use way direction in their 
semantics.


David

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway direction


 On 01.09.2010 08:32, Nathan Edgars II wrote:

On Wed, Sep 1, 2010 at 2:16 AM, Pierre-Alain Dorangepdora...@mac.com  wrote:

so flow_direction ?

How would you know if local waterways have the wrong direction without
specifically checking for the problem? OSM relies on the enough
eyeballs principle for finding major errors.
of course, but Mapnik is not the application to show everything which 
could be a modelling error.

Mapnik is a renderer for a map.

To find errors, use the database or specialized tools like the ones from 
Geofabrik.
If there is no tool for checking waterway directions, perhaps someone 
has to build one!?


If you can see errors at mapnik, that's good - but don't change Mapnik 
to visualize more errors.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sport=beachvolleyball?


 Hi.
Could be invented by non-English speakers. In German it's 
Beachvolleyball as one word - other languages could be similar, don't know.


regards
Peter

On 01.09.2010 07:18, Nathan Edgars II wrote:

I'm wondering if there's a reason this is beachvolleyball rather than
beach_volleyball. Most other tags seem to have underscores where
spaces would go between words.

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Craft

2010-09-01 Thread Peter Körner


Hi all friends of good tagging,

The proposal is opened for one week now and I plan to put it to voting 
phase at Tu, 7.9.2010. If you have any comments or ideas or think that 
the proposal needs to be changed significantly, I'd like you to speak up 
during the next week.


Peter


Am 24.08.2010 21:16, schrieb Peter Körner:

Hi all

I announced the unofficial proposal on this list already. I moved it
into the regular proposal cycle by creating a proposal-page for

Craft - A place producing or processing customized goods
http://wiki.openstreetmap.org/wiki/Proposed_features/Craft

Please comment - here or on the Discussion Page..

Peter



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Craft


 ironic
Is the place where the Mapnik server is housed craft=tiler in future?
/ironic

+1 for the proposal from me.

Peter Wendorff

On 01.09.2010 09:37, Peter Körner wrote:

Hi all friends of good tagging,

The proposal is opened for one week now and I plan to put it to voting 
phase at Tu, 7.9.2010. If you have any comments or ideas or think that 
the proposal needs to be changed significantly, I'd like you to speak 
up during the next week.


Peter


Am 24.08.2010 21:16, schrieb Peter Körner:

Hi all

I announced the unofficial proposal on this list already. I moved it
into the regular proposal cycle by creating a proposal-page for

Craft - A place producing or processing customized goods
http://wiki.openstreetmap.org/wiki/Proposed_features/Craft

Please comment - here or on the Discussion Page..

Peter



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - power generator rationalisation

2010-09-03 Thread Peter Wendorff


 On 04.09.2010 00:16, Pierre-Alain Dorange wrote:

Tom Chancet...@acrewoods.net  wrote:


Please vote on my proposal:

http://wiki.openstreetmap.org/wiki/Proposed_features/generator_rationalisation

It has gone through several weeks of discussion on this list and on the
wiki. I have made significant changes to the proposal to make it as flexible
as seems sensible.

If voted through, I will look at updating existing data in OpenStreetMap.

I do not follow this discussion, but automatic data update is generally
not welcome on OSM.
It can/would modify data made by people that don't know your discussion
and would be hurt by a big modification behind there back.

I think it would be preferable before any automatic update to contact at
less the people that create lot of generator it inform then directly.
Dont assume all osmer read this list.

+1
In this case as far as I can see the proposal only defines new Tags to 
replace the old ones.
AS that does not affect the old data I would agree with automatic 
updates in this case, as long as the old tags are not deleted during the 
update.
Of course that produces redundant data - but it solves the problem you 
mention, and afaik doesn't create other problems:

- the old stuff stays in the database (as long as nobody deletes it by hand)
- the new stuff comes into the database and mappers dealing with 
generators learn about it due to wiki lookups after the changes.


With this in mind:
automatic additions are okay (using a little bit brain), automatic 
deletions should be avoided from my POV.


regards
Peter


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Relation for saying x is attached to y?

2010-09-04 Thread Peter Wendorff


 On 04.09.2010 07:00, Steve Bennett wrote:

Any existing renderer would not render C at all. Any renderer (or
other tool) that added support for railway=train_line, would
presumably also add support for the relation.

As that's right from the applications point of view, keep in mind the 
need for mapping people.
Artificial, virtual lines like these are good for the renderers - but 
complicated in editor software: I have

1) to know about the train_line concept
2) to move this way additionally

I'm sure, there has to be a way for renderers to collapse parallel ways 
to one - without explicit tagging in the database.

The railway example is only one of more examples.

If collapsing takes into account the number of collapsed tracks to 
consider it for the signature in the map - even better.


regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Homeless Shelter

2010-09-04 Thread Peter Wendorff


 Hi.
Should not building=homeless_shelter be correct - and thus more precise 
than the big collection amenity?


Peter

On 04.09.2010 03:24, Sean Horgan wrote:

Dear mappers,

I scoured the well-written wiki pages for a similar feature but 
couldn't find one so here is a proposal for a Homeless Shelter:


http://wiki.openstreetmap.org/wiki/Proposed_features/Homeless_Shelter

This is my first crack at a proposal so I'm looking forward to all 
suggestions and comments.


Thanks.

Sean


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=single family houses/apartments

2010-09-04 Thread Peter Wendorff

 Aside of your question: you should use : instead of . to separate 
language tokens from normal tagnames.

And AFAIK it's not a good idea to translate every value like you do it here.
The translations/languages should only apply to names, not on classes.
If your Application wants to use different languages than English, it 
should use a dictionary for that at client side.


regards
Peter

On 04.09.2010 18:12, Erik Johansson wrote:

Hi

I would like to tag areas with apartment buildings, and small houses
for a  single family differently, at the moment I tag all of them with
  landuse=residential. I need good terminology in english to tag them.

This is from swedish wikipedia:
http://sv.wikipedia.org/wiki/Flerfamiljhus#Typer_av_flerbostadshus
http://sv.wikipedia.org/wiki/Sm%C3%A5hus

So that would be something like:
landuse=residential
residential.en=[ apartmentbuildings | villas | small houses | vacation
houses | farmbuildings]
residential.sv=[ flerbostadshus | villområde | småhus | fritidshus |
radhus | miljonprogram] etc.




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Relation for saying x is attached to y?

2010-09-05 Thread Peter Wendorff


 On 05.09.2010 09:23, Steve Bennett wrote:

On Sat, Sep 4, 2010 at 6:58 PM, Peter Wendorff
wendo...@uni-paderborn.de  wrote:

I'm sure, there has to be a way for renderers to collapse parallel ways to
one - without explicit tagging in the database.
The railway example is only one of more examples.

Right, to do this well we'd really need to work out some good use cases.

Incidentally, a middle ground option would be to have an relation that
indicates that the two tracks are indeed parallel and form a pair. A
renderer could use that information to compute a middle line when
required.


If collapsing takes into account the number of collapsed tracks to consider
it for the signature in the map - even better.

The signature? What do you mean?
Well - I fear, I used the word with one of meanings it has in German - 
but probably not in English

http://de.wikipedia.org/wiki/Signatur_%28Kartographie%29

A Signatur - other meanings can be translated to the English 
signature - in the context of cartography is the style a map feature 
is visualized - an icon, the style and colors of a line and so on.


;) What's the English word for that?

Regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging single trees

2010-09-06 Thread Peter Wendorff


 Additionally:

If you know, that the trees you have added in the past are conform to 
the definition as single or significant feel free to change that to 
all trees you mapped in the past.
That should be relatively simple by fetching all trees with your 
username and retagging them.


regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Craft


Hi All,

after two weeks without contradictions, I'll open up voting for the 
Craft proposal:

  http://wiki.openstreetmap.org/wiki/Proposed_features/Craft

Thank you for your vote.

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging single trees

2010-09-07 Thread Peter Wendorff


 I have an additional analysis task:

We know how much trees are tagged with, and how much are tagged without 
additional tag, but:

1) How much users added trees with additional tags?
2) How much users added trees with additional tags and trees without?
3) How much users added trees without additional tags in a later 
changeset then trees with additional tags?
4) How much trees have additional tags describing the importance, where 
these are added later by the original contributor of the tree node?

5) same as 4) but with different users

Question 1 would be good to compare against the users who never used the 
more precise tags
Question 2 could show users using natural=tree with knowledge about the 
additional tags - so probably aware of the additional tags

Question 3 goes into the same direction as Question 2
Question 4 should point out specializations made later
Question 5 could probably show, that adding simply a tree by one user 
motivates other people to add more data.


regards
Peter

On 07.09.2010 17:24, NopMap wrote:


John F. Eldredge wrote:

It seems reasonable to me that a node simply tagged as a tree, with no
other information, could be single or not-single, a landmark or not a
landmark.


Again. We are not freely discussing a model to implement in the future. We
have a lot of work already done. And if there is a definition for a tag,
undisputed and unchanged for 4 years, and people use the tag in a fitting
manner, isn't it the most sensible thing to assume that they actually knew
what they were doing and meant exactly what the definition says?



John F. Eldredge wrote:

 From here on, in other mails, you use the German numbers as if they're
the only numbers.


They are the only numbers I have. Do you have more?


John F. Eldredge wrote:

It doesn't seem anyone's mind is being changed at this point, so I'd
like to second Martin's suggestion that we move to the voting phase.


The statistics indicate that between 76% (German evaluation by myself) and
87% (global evaluation by Fabian Schmid) of the users who entered/touched a
node used it according to the current definition in the wiki. It does not
make sense to vote on any change if the actual use confirms the existing
state with a vast majority while the masses of nonconformant nodes come from
only a very small number of users.

bye
Nop




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft




Am 07.09.2010 18:01, schrieb M∡rtin Koppenhoefer:

craft=fashion should be fashion_designer to correpond to the
translation, but still this is not a craft. I would put it in office.

I don't think so, but I'd be happy to discuss the pros and cons.

I see a fashion_designer as somebody who is creating custom-made 
clothes. Because he's creating something, it's a craft.



jeweler is AE ,use jeweller (BE)

i'd acknowledge.


craft=photo is too generic, there is not explanation given (just
questionmarks), and it isn't a craft IMHO.
it was added by some one else. I'd suggest photograph/photographer, or 
to follow the other values, photographing.



instead of staging I'd use scaffolding

i'd acknowledge.


I'd consider all of these corrections minor, so voting shouldn't be affected.
If no one speaks up, I'll make two changes to proposal 
(staging-scaffolding and jeweler-jeweller) and invite all to comment 
on the other two requested changes.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft


Am 07.09.2010 18:27, schrieb John Smith:

I'd also consider things like hairdresser to be in shop, even though
it might be seen as a craft,
I'd too regard craft=hairdresser as an uncommon combination. Any votes 
against removing craft=hairdresser from the list of common values?


 same with handicraft (shop=craft),
I see a differenct between producing handicraft work (craft=handicraft) 
and selling it (shop=handicraft). If both is located in a single place, 
there's no problem in dual-tagging with both keys.



locksmith (shop=locksmith)
I don't see a locksmith as a shop, even if it's usually called like 
that. In german it's called dienst (service) so it should maybe be 
office=locksmith but that doesn't match it either.


Looking at the tag definition, it would be a craft because it's creating 
custom-made things.


 optician (shop=optometrist), saddler

(shop=saddlery) as that is how these are commonly referred to in
english...
My arguments for keeping them are similar to those above for 
shop/craft=handicraft. There are always two parts involved: one is 
producing and one is selling. Sometimes one is more important and 
sometimes the other one. If both are similar important, there's no 
problem with adding both tags.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft




Am 07.09.2010 18:31, schrieb John Smith:

craft=mechanic
mechanic=[agriculture|marine|automotive]


If craft=mechanic includes building custom machineries, then I'd like 
with this idea, otherwise i like Agricultural Equipment best.


Same for

craft=carpentry
carpentry = [formwork|cabinetry|framing|etc]

If no one opts against this, I'll change the proposal accordingly. Does 
anyone think this would invalidate the given votes?


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft




Am 07.09.2010 18:54, schrieb Brad Neuhauser:

I guess I'm a little confused by the description A place producing or
processing customised goods as it doesn't seem to fit some of these
occupations, especially what I'd think of as the building trades:
HVAC, electrician, carpentry, carpet, roofing, plaster, plumber, etc.
Maybe A place is the wrong part. A carpentry is producing a customised 
good (eg. a house) or at least it's processing a part of it (the 
carpet), but this does no happen at the node's place.



  At least in the US, these workers usually do their work on-site, and
while they may have a office or building they're based at, they may or
may not even go there daily.  So, nothing much is produced or
processed at the location that would be tagged in OSM.  So, maybe a
different description, or different tag for these. I see there's already
a different usage described on the wiki for shop=trade, but to me, it
would make sense to tag shop=trade, trade=plumbing|roofing etc.


shop=trade reads A place of business that specifically sells one or 
more building supplies such as timber/wood, cement etc. so it's about 
selling. craft=carpentry is about using the material sold there to 
actually do something.



One side note
One side note from me I'd ask for your understanding: It's so hard to 
follow all these wording issues if you're no native speaker. I really 
need your help to find the correct terminology.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft


Am 07.09.2010 21:43, schrieb M∡rtin Koppenhoefer:

IMHO that's a taylor. A fashion designer is designing clothes that
then get produced in the textile industry.

I removed craft=fashion from the list


craft=photo is too generic, there is not explanation given (just
questionmarks), and it isn't a craft IMHO.


it was added by some one else. I'd suggest photograph/photographer, or to
follow the other values, photographing.



If no one speaks up, I'll make two changes to proposal (staging-scaffolding
and jeweler-jeweller) and invite all to comment on the other two requested
changes.

I applied those changes and added photographic_laboratory.

I'm not happy that these questions did't came up during RFC stage but 
now during the voting stage. Does anybody think this is a problem for 
the validity of the votes?


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Craft

2010-09-14 Thread Peter Körner


Am 07.09.2010 13:31, schrieb Peter Körner:

after two weeks without contradictions, I'll open up voting for the
Craft proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Craft


The Voting has now been open for 1 week and so far we have 25 people 
approving the proposal. The voting will be open for another week now and 
I'd encourage everyone that hasn't done this till now, to give his vote 
and comments.


Thank you all,
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OpenStreetMap] social facility

2010-09-14 Thread Peter Wendorff


 Hi.

On 14.09.2010 18:59, Sean Horgan wrote:

[...]
Also, if I wanted to capture specific data about that they offered, 
I'd like to follow the amenity:recycling tagging scheme 
(http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling):


+ homeless_shelter:programs=jobs
+ homeless_shelter:meals_served=breakfast
+ homeless_shelter:lodging=yes
+ homeless_shelter:emergency_medical=yes

Is this a good model to follow?

I'm not sure.
I think, there are two general approaches to simulate a tree-style 
tagging scheme like this.
The first is to use more keys (as you do here with homeless_shelter:*), 
the second is to use more values and to concatenate multiple values by ; 
(like you will have at

homeless_shelter:meals_served=breakfast;lunch
(compare crossing=island;traffic_signals)

Both are good for some reasons:
using less keys provides easy access for the whole group of values;
using less values is more easy to parse and search - there is no string 
slicing needed.


But:
I would not mix these together.

Perhaps that's only my POV - feel free to argument against.

regards
Peter
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: more barrier types

2010-09-20 Thread Peter Wendorff


 On 20.09.2010 20:27, M∡rtin Koppenhoefer wrote:

Hi,

I'm asking for comments to the new barrier types listed here:
http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types

If you miss something, please report here so that we can extend the
proposal. I somehow forgot about it, but want to close the process now
in some weeks time by voting, so that we can add the values to the
feature page.

There is also an addition for control devices (see subtags on the
page) to be part of the proposal. What do you think, are these
(RFID-reader, PIN-Code-Keypad, Key, etc.) better in barrier or in
access? Maybe access is worse because it is about legal restrictions.
I don't see for most of these additions where they relate to the barrier 
itself:
barrier:video does not differ relevant from normal video surveillance 
- so I don't see the need for another tag.
keys: well - okay, but that's from my POV only useful when standard keys 
(like Euro key for toilets for disabled people or the square shaped key 
for bollards often used at least in Germany) is used. These I would add 
more concrete to avoid different interpretations of key and to 
increase the use of the key.
rfid: useful for other features as well, and I think, tagged as a 
barrier node the relation would be clear enough - or are there any use 
cases for a barrier where rfid would relate to another entity than the 
barrier itself? same for keypad, rfid, biometric and magnetic_stripe.


regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: more barrier types

2010-09-20 Thread Peter Wendorff


 On 20.09.2010 21:50, Tobias Knerr wrote:

M∡rtin Koppenhoefer wrote:

I'm asking for comments to the new barrier types listed here:
http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types

Nice collection of missing barrier types. I've even used some of them
already, so it's a good thing to document these additions.

I noticed some smaller issues, though:

* Couldn't we just use barrier=rope/chain on ways, too? Introducing
barrier=post_and_rope/post_and_chain for this seems unnecessary.

* Isn't a guardrail a linear feature? It should be possible to use this
on ways.

* barrier=curb has an area element type. This seems /somewhat/
excessive, especially since none of the other barriers has.
I think, it's good to apply barrier=curb on closed ways, too, but that 
should NOT imply the inner of the polygon to be raised above the outer 
part. There can also be a polygon lowered.
With that in mind, it's not tagging as area, it's tagging the way - 
although the way is closed.


regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Interpreting One feature, one OSM-object

2010-09-23 Thread Peter Wendorff


 Hi Richard.
Never heard of that, so let me ask to clearify...

On 23.09.2010 00:59, Richard Welty wrote:

 On 9/22/10 6:47 PM, Andrew Harvey wrote:

What happens if tags conflict then? For example just say the boundary
actually had a name, e.g. X Y Border, but the river also has a
different name.

one of the operative theories here is that in cases of shared ways,
we should be using the higher level relations that contain the ways to
provide the distinction.
Following situation: There are two shops inside the same building and 
the building is a node only, yet.
Let's assume the position of the shops cannot be distinguished - 
examples can be found in discussions about e.g. post offices together 
with stationery shops etc.


If I interpret your statement correct, you propose to tag that as follows:
1) the node contains address data (and of course the coordinates)
2) a relation contains the node and the data for the stationery shop
3) a second relation contains the same node and the data for the post 
office.



If I am right with this interpretation, I come to new questions:
1) What kind of relation should (2) and (3) be?
2) Is that stuff supported by common renderers (interpretation of 
relations to show simple POIs?
3) How can we achieve to support that model in editors, as IMHO editing 
relations is much harder than editing simple geometry objects 
(nodes/ways), but this model would lead to more need for relations.


Nevertheless I think, it could be a very useful scheme to generally 
support grouping tags together while differentiating several groups on 
one geometry object.


regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Railway routes in different directions.

2010-09-23 Thread Peter Wendorff


 Hi.
At first, I would say, there is no railway routing algorithm similar to 
one for cars or pedestrians.

There even is no allowed direction of one of the routes usually.

So I would do it the following way:
- the track should be tagged as one single line, divided into two 
different lines along the platforms
- no oneway at the track as it's no legal restriction; it's a usage 
decision of the railway operator, I think.
- If you add the routes as relation, add the parts that apply - 
different for each direction at least along the platforms.


the relation is AFAIK interpreted in order of it's elements or vice 
versa. Per role you can define forward only or backward only for parts 
of the route.


Compare http://wiki.openstreetmap.org/wiki/Relation:route#Members for 
details.


regards
Peter

On 23.09.2010 20:53, Dave F. wrote:

 Hi

I've a railway routes that's drawn as a single line with a relation 
added; except where the tracks become wider apart to go each side of a 
platform where they are two lines.


Does routing software need the relation to differentiate between the 
directions? Up/Down, Forward/Backward?


And how would you decide which direction is which?

Cheers
Dave F.

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tag craft is part of map-features

2010-09-23 Thread Peter Körner


Hi

The new tag craft has been approved by 35 voters and so I moved on and 
pushed it to map-features:


http://wiki.openstreetmap.org/wiki/Map_Features#Craft
http://wiki.openstreetmap.org/wiki/Key:craft
http://wiki.openstreetmap.org/wiki/Tag:craft%3Dcarpenter

Thank you for your votes.

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Craft

2010-09-26 Thread Peter Wendorff


 Hi.
I miss a value for a print office (don't find a better translation for 
the German Druckerei).


There is shop=copyshop, but I think, we should divide between these two:
Both creates prints or copies of media as books, papers, advertising 
etc., but a copyshop usually does this in smaller scale (not as much 
copies), usually more concentrated on private customers.
A Druckerei/print office is more concentrated on more or less mass 
production of print articles like newspapers, books etc.


I would like to add this to craft, but I don't know a good english value 
for that.


Any ideas?

regards
Peter

On 01.09.2010 09:37, Peter Körner wrote:

Hi all friends of good tagging,

The proposal is opened for one week now and I plan to put it to voting 
phase at Tu, 7.9.2010. If you have any comments or ideas or think that 
the proposal needs to be changed significantly, I'd like you to speak 
up during the next week.


Peter


Am 24.08.2010 21:16, schrieb Peter Körner:

Hi all

I announced the unofficial proposal on this list already. I moved it
into the regular proposal cycle by creating a proposal-page for

Craft - A place producing or processing customized goods
http://wiki.openstreetmap.org/wiki/Proposed_features/Craft

Please comment - here or on the Discussion Page..

Peter



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Craft

2010-09-26 Thread Peter Körner




Am 26.09.2010 13:09, schrieb Elizabeth Dodd:

On Sun, 26 Sep 2010 12:16:14 +0200
Peter Wendorffwendo...@uni-paderborn.de  wrote:



I would like to add this to craft, but I don't know a good english
value for that.


Printery


Please remember to add it to the offiial Tag-Page [1] and not to the 
outdated proposal page from this thread.


Peter

[1] http://wiki.openstreetmap.org/wiki/Key:craft

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] inconsistencies in bridge

2010-09-28 Thread Peter Wendorff


 On 28.09.2010 02:48, John Smith wrote:

On 28 September 2010 10:38, Dave F.dave...@madasafish.com  wrote:

If historic data was kept within OSM it would become far to cluttered.

Not if this data was filtered by default, and only shown if requested.
The present method of showing everything is limiting for a number of
reasons.

+1
I think, we should start thinking about a new dimension time in 
generally. Perhaps this should better be in the API/attributes similar 
to lat/long instead of inside the tagging, because it's more an 
additional coordinate than a property.
Build in the API the default way to show only current data is easy to 
support, too.

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Successful proposal

2010-10-12 Thread Peter Körner


Am 12.10.2010 18:02, schrieb M∡rtin Koppenhoefer:

Am 12. Oktober 2010 17:31 schrieb Matthias Meißerdig...@arcor.de:

We identified the problem on the german mailinglist:
http://forum.openstreetmap.org/viewtopic.php?id=9586
I think there is a different problem, as the user who removed the item 
from the map-features list did this with an other intention. Following 
his user page [1] he's no friend of the proposal process and his main 
problem was the small number of uses of this tag [2].


I can follow this argumentation but it makes it hard to have two sets of 
rules to follow when creating tag-pages in the wiki.


I contacted him and we'll what will be the result of this discussion.


What about closing the forum and redirecting them to the mailing-list
archive? There is always complaints in the forum, that nobody told
them this and that, and if they were following the main discussions
( ;-) ) this could be avoided. The ML-archives are like a forum,
aren't they?


Some people like this, some like that. In this discussion it seems that 
telling the Thread-OP to come to the ML would not have made it easier to 
talk to him, so it was best to come with him and discuss it there.


There still should be one common channel to send important notifications 
to both discussion lists, but that should not be discussed on this list.


Peter

[1] http://wiki.openstreetmap.org/wiki/User:Jonobennett
[2] http://taginfo.openstreetmap.de/keys/craft

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Successful proposal

2010-10-13 Thread Peter Körner


Am 13.10.2010 09:31, schrieb Matthias Meißer:

For this proposal IMHO the users who removed the proposal should be
notified and the author should be allowed to add his new feature to the
map features page. He fullfilled all requirements with his proposal


I contacted him and we're still in a very interesting discussion. His 
opinion is, that the map-features should list the *most common used* 
features and it's clear that with 500 uses, craft does not fall into 
this category. So I can accept this tag not being listed on map-features 
but findable via a the search. This is a definition problem of what 
should be on the map-features page.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Successful proposal

2010-10-13 Thread Peter Körner


Am 13.10.2010 13:54, schrieb NopMap:

Considering the reversal of the crafts entry
He did not reverse anything, the craft tag and all documentation is 
still there, its just not listed as a common used tag (because it's not 
common used right now).


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Successful proposal

2010-10-13 Thread Peter Körner


Am 13.10.2010 16:04, schrieb M∡rtin Koppenhoefer:

what about removing highway=byway from the mapfeatures? It is used
less then 2000 times (which is very little for highway), and it is
UK-only, so IMHO no reason at all to be listed on the main features
page, could be moved to mapfeatures UK.


Yes I would approve that. Same with geological which is only used 120 
times worldwide. Let's clean the map features list!


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Country names

2010-10-13 Thread Peter Budny

Looking at very high zoom levels on Mapnik, I noticed that the East
Asian countries (Japan, China, etc) have their names written in native
script with the English name in parentheses, but a lot of other
countries (e.g. all the ones with Arabic characters) don't seem to
follow this.

Why the inconsistency?  Either way makes sense, but shouldn't we pick
one and stick with it?
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names


Am 14.10.2010 08:39, schrieb Jochen Topf:

And one problem they have is that maps are hard to use if you
can't read half the country names.



This is one of those problems that will not be solved until the renderers
get more clever and, for instance, take the name tag and the name:en tag
and put them together in the local name (english name) form. Only then can
we tag this consistently. (Feel free to work on that problem :-)

This sounds doable in the Style's SQL Statements. Currently we use

SELECT name AS local_name,
   COALESCE(tags-'name:en', name) AS display_name
  FROM planet_point
 WHERE tags @ 'place=country'
   AND NOT name IS NULL;

but we may also use
SELECT name AS local_name,
   CASE WHEN name != (tags-'name:en')
THEN name || ' (' || (tags-'name:en') ||')'
ELSE name
END AS display_name
  FROM planet_point
 WHERE tags @ 'place=country'
   AND NOT name IS NULL
 LIMIT 10;

I could set up such a style on the toolserver if it would be helpful, 
but I'd like to point to the localized maps we currently have in 30 
languages: http://toolserver.org/~osm/locale/ (use the layer switcher).


Peter


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names


Am 14.10.2010 12:41, schrieb Andrew Errington:

This generalises to if language lang is requested then use name:lang=* if
such a tag is present.  If it's not present then use name=*


That's exactly what we do on the locale maps on the toolserver for the 
30+ languages listed there.



Anyway, my point is, and I do have one, if I look at the website
(http://toolserver.org/~osm/locale/) I see English labels when I select
osm-labels-en (presumably taken from name:en=*) but I see the combined
Hangul+(English) when I select osm-labels-ko.  Presumably these are being
taken from name=* when they should be taken from name:ko.
This is done for places that do not have a name:ko tag. As an example 
I'd take the place-node of china [1] which does not have a name:ko, so 
the rendering style takes the name-tag. You may want to look at my old 
country translation tool [2] so see which tags need to be checked and 
which tags should be translated.


Be aware that the small zoom levels on the toolserver (0-6) are only 
rerendered once a month (sooner if you /dirty them).



Aside from that, it's super-awesome.
Thank you. It's basically an experiment of getting localized maps into 
the Wikipedia.


Peter


[1] http://www.openstreetmap.org/browse/node/424313582
[2] http://toolserver.org/~mazder/multilingual-country-list/?lang=ko

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names

2010-10-14 Thread Peter Wendorff


 I'm not sure, if that's a good solution...
It's relatively simple and can be done automatically, but do it hit the 
target?


For most Asian and Arabian countries that would help perhaps: the native 
language uses other character (sub)sets and therefore the rest of the 
world probably don't know how to read it, but let's consider Europe:


Deutschland = Germany: yes, sounds like a good idea for international use
France = France: sounds useless as these are the same (well - you 
ignored same values in the query)
Belgien (german), /België/ 
http://upload.wikimedia.org/wikipedia/commons/e/e6/Nl-Koninkrijk_Belgi%C3%AB.ogg^ 
http://de.wikipedia.org/wiki/Hilfe:Audio 
http://de.wikipedia.org/wiki/Datei:Nl-Koninkrijk_Belgi%C3%AB.ogg 
(netherlands), /Belgique/ (france), Belgium (Englisch)... - is that 
useful to put both onto the map? It's similar in a human mind, I think.


That in mind I would say, we should search for a more sophisticated 
solution; and the best thing (while much work to do) would be to have 
language specific label layers.


regards
Peter

On 14.10.2010 09:59, Peter Körner wrote:

Am 14.10.2010 08:39, schrieb Jochen Topf:

And one problem they have is that maps are hard to use if you
can't read half the country names.


This is one of those problems that will not be solved until the 
renderers
get more clever and, for instance, take the name tag and the 
name:en tag
and put them together in the local name (english name) form. Only 
then can

we tag this consistently. (Feel free to work on that problem :-)

This sounds doable in the Style's SQL Statements. Currently we use

SELECT name AS local_name,
   COALESCE(tags-'name:en', name) AS display_name
  FROM planet_point
 WHERE tags @ 'place=country'
   AND NOT name IS NULL;

but we may also use
SELECT name AS local_name,
   CASE WHEN name != (tags-'name:en')
THEN name || ' (' || (tags-'name:en') ||')'
ELSE name
END AS display_name
  FROM planet_point
 WHERE tags @ 'place=country'
   AND NOT name IS NULL
 LIMIT 10;

I could set up such a style on the toolserver if it would be helpful, 
but I'd like to point to the localized maps we currently have in 30 
languages: http://toolserver.org/~osm/locale/ (use the layer switcher).


Peter


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names


Am 14.10.2010 15:47, schrieb Craig Wallace:

On 14/10/2010 14:36, Andrew Errington wrote:


So, when we get a renderer that can render name:ko + (name:en) we
can delete
all name=* which have been typed in that form and then rename
name:ko=* to
name=*


No, this would not be helpful. Because then how do you know what
language the name tag is in?
More useful to leave the name:ko tag as it is. Though you could copy
(not rename) the name:ko tag to the name tag if you want.


To render a German map there are two possibilities:
1. render name:de if it exists, name otherwise
2. render name if its identical to name:de, name (name:de) otherwise

name does hereby refer to the local name ((how do the people that live 
there call their country).


This works for all the places that have only one local name. 1. is waht 
we currently render on the TS and it would be easy to set up 2., but it 
would not look nice because the name tag sometimes already contains 
brackets.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names


Am 14.10.2010 15:56, schrieb Richard Mann:

You can also test for the presence of name:de in name, rather than
just equality, so that if name contains (say) French/German/Flemish
components, then you use that rather than making your own name
(name:de) combination.


That would be:

SELECT name AS local_name,
   CASE WHEN NOT name ~* (tags-'name:en')
THEN name || ' (' || (tags-'name:en') ||')'
ELSE name
END AS display_name
  FROM planet_point
 WHERE tags @ 'place=country'
   AND NOT name IS NULL
 LIMIT 10;

I'ts so simple.

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names

2010-10-14 Thread Peter Wendorff


 Hi.
Tweaking the renderer this way is the wrong decision, I would say.
For me the problem is the mixed name stored in some name tags, e.g. 
local-name (english name) as mentioned before.
Your idea here is to make the renderers better to avoid the NEED of that 
crap (to be clear: as a workaround it's okay, but it's crap from the 
data point of view).
If changing the renderer - why not change it correctly to use name + 
(name:en) (if that's what we want for name containing only the local name).


There will be people fixing the bugs done as workaround yet - I'm sure;
and as a result we will get a better database with maps similar or equal 
to the maps we have now, but perhaps with the far view towards real 
multi-language rendering using e.g. different language layers.


regards
Peter

On 14.10.2010 16:03, Peter Körner wrote:

Am 14.10.2010 15:56, schrieb Richard Mann:

You can also test for the presence of name:de in name, rather than
just equality, so that if name contains (say) French/German/Flemish
components, then you use that rather than making your own name
(name:de) combination.


That would be:

SELECT name AS local_name,
   CASE WHEN NOT name ~* (tags-'name:en')
THEN name || ' (' || (tags-'name:en') ||')'
ELSE name
END AS display_name
  FROM planet_point
 WHERE tags @ 'place=country'
   AND NOT name IS NULL
 LIMIT 10;

I'ts so simple.

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names


Am 14.10.2010 16:42, schrieb Craig Wallace:

On 14/10/2010 14:51, Peter Körner wrote:

To render a German map there are two possibilities:
1. render name:de if it exists, name otherwise
2. render name if its identical to name:de, name (name:de)
otherwise

name does hereby refer to the local name ((how do the people that live
there call their country).



But what if you want to render a map with only German names, no other
(local) languages?
That's version 1. If I don't have a name:de then name is the best guess. 
No Problem here.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names

2010-10-14 Thread Peter Budny

Noel David Torres Taño env...@rolamasao.org writes:

 That all is quite good for places with only one roman-script name. But I'm 
 thinking in this case:

 name:es=Cataluña (This is the name in Spain's official language, which is 
 official there since Catalonia is part of Spain)
 name:ca=Catalunya (This is the official name, it is in local language)
 name:en=Catalonia (This is the name in OSM's official language)

 How to tag name=* for that? How to render?

 An it can become more complicated, as in Basque Country most places have both 
 spanish and basque names as official:

 name:es=Vitoria (=name:en)
 name:eu=Gasteiz

 official name: Vitoria/Gasteiz

 and some places where both names are the same (like Barakaldo) so official 
 name is obviously not Barakaldo/Barakaldo

 or, just with one local and official name, but different names for people 
 which use that map a lot, like british and german tourists in Canary Islands:

 name:es=Islas Canarias
 name:en=Canary Islands
 name:de=Canarische Inseln

There's a problem in places like Hawaii, too.  Officially, Hawaiian uses
the kahakō and the ʻokina.  English does not.  However, there are
streets with names like Kalākaua Avenue and Liliʻuokalani Avenue.

The name:en= tag should not contain kahakō or ʻokina.  However, the
name:haw= tag should not contain words like street or avenue,
because these are English words!

The best solution, then (and I mean this for all places, not just
Hawaii) seems to be to tag name= with exactly what's written on the
signs.  If more than one language is used on signs, choose whichever is
larger/more prominent/on top.

This has added value in that you can give directions that tell the user
to turn left on Liliʻuokalani Avenue or take the exit towards
München and they'll be able to look for a sign that says exactly that,
without the router needing to know anything about what the local
language is.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names

2010-10-15 Thread Peter Körner


Am 15.10.2010 08:21, schrieb Stephen Hope:

So the sign Rue Bouganville St would be name:en=Bouganville Street,
name:fr=Rue Bouganville, but what would you put in name=?


Exactly what's on the sign: Rue Bouganville St

Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] How can the US get its stuff together? (was Re: Response to A critique of OpenStreetMap)

2010-10-16 Thread Peter Budny

Richard Weait rich...@weait.com writes:

 On Sat, Oct 16, 2010 at 8:22 AM, Phil! Gold phi...@pobox.com wrote:
 * Richard Fairhurst rich...@systemed.net [2010-10-14 10:47 -0700]:
 I think you could largely sum up his criticisms in two broad headings:

    1. US OSM contributors need to get their shit together
    2. European maps don't look like American ones

 I'm trying to see what sort of consensus exists on some of the issues from
 41 latitude's post.  I've sent an email to the talk-us list[0] asking for
 feedback and discussion.  I encourage anyone who's interested, particulary
 people who map in the US, to contribute to the discussion on that list.

  [0]: 
 http://lists.openstreetmap.org/pipermail/talk-us/2010-October/004361.html

 The North American interest in highway signs may be difficult to
 understand around the world.  If I remember correctly one of our
 Euro-colleagues referred to highway shields as looking a bit naff.
 I think that means good though.

 So, highways and road culture play a large role in the life of many
 North Americans, there are even songs that we know like Route 66, and
 Highway 61 that show affection for specific roads.  There are others.
 Many others.  I was surprised to find this list of road songs on the
 official US Federal Highway Administration web site.  That may help to
 define the scope of the interest (problem) for our friends who don't
 see the attraction of highway shields.  Even the humorless official
 bodies in North America like a good road song.

 http://www.fhwa.dot.gov/infrastructure/roadsong.cfm

For better or worse, that made me think of images like
http://failblog.org/2008/07/03/sign-design-fail/

Whether it's a good thing or not, we still have to figure out how to tag
it.  Bear with us.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=kiosk

2010-10-17 Thread Peter Wendorff


 Hi Martin.
I fear, this proposal would not lead to a better solution - at least, as 
long there is no good solution for the multivalue-problem discussed 
currently.


I think, shop=kiosk referres to a usual mixture of goods sold there: 
newspapers, lottery-stuff, tobacco, sweets.


shop=newspapers would be wrong - that IMHO are the shops often found in 
train stations selling newspapers only (but usually with a wider, often 
international diversity).
shop=tobacco is completely different in some countries; often 
concentrating on pipes, ziggarrs (is that the correct english word?) 
etc., while a kiosk usually sells standard cigarrettes in it's main focus.
shop=lottery-stuff is often a kiosk (at least here in Germany), but I 
would prefer to tag lottery stuff as an additional tag.
Even sweets are no good solution as single value as sweet shops don't 
sell the other goods mentioned here.


Using building=kiosk, shop=* with these values would lead to 
shop=sweets, tobacco, lottery-stuff, newspapers - and every other 
alternative order of these values.
Using building=kiosk additionally would be wrong for every kiosk build 
in a common house, like shown on these pictures:

http://www.flensburg-online.de/fotos/kiosk-blasberg.jpg
http://www.jazzplayseurope.eu/jazzwerkruhr/wp-content/uploads/2010/04/kiosk.jpg

Of course you are right: there is the building type kiosk, and I 
think, it's worth to consider that for tagging as building=kiosk, but it 
should not substitute the shop=kiosk.


regards
Peter

On 17.10.2010 11:52, M∡rtin Koppenhoefer wrote:

shops should be tagged with shop=shop category, which refers to the
kind of stuff sold, also in cases like supermarket or convenience,
which are less obvious then e.g. shop=electronics.

shop=kiosk breaks this rule, as it doesn't refer to the sold products
but to the building typology.

Therefore I'd like to propose to use building=kiosk and mark
shop=kiosk as deprecated. The 10184 uses of shop=kiosk should be
retagged by local mappers to indicate the product(s) sold (newspaper,
fast_food, lottery-stuff, tobacco, etc.)

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Country names

2010-10-18 Thread Peter Körner


Am 15.10.2010 15:02, schrieb Emilie Laffray:



On 15 October 2010 13:55, j...@jfeldredge.com
mailto:j...@jfeldredge.com wrote:

How would you handle the situation of what is on the sign being in
more than one character set, such as a sign being labeled in both
English (in Roman letters) and Arabic (in Arabic letters)?  From
photos I have seen, this is not uncommon in large cities, in
countries where the local language or languages use non-Western scripts.


As far as I am aware, OSM is storing the data in UTF-8 and mixing two
scripts is not a problem.
Inputting it might be a problem but if you get local people to do it, it
is not a problem.


It may get a problem in a BiDi Scenario but this is up to the UI of the 
editors and the renderers.


Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=kiosk

2010-10-18 Thread Peter Wendorff


 On 18.10.2010 10:42, SURLY_ru wrote:

So there is no typical assortment of goods sold in kiosks.

May be in the international scope - and therefore you are right, I think.

It would be better
to tag kiosks as ordinary shop (shop=convenience, shop=news_agent,
shop=greengrocer or even shop=general) with addition of building=kiosk.
But as mentioned before, the term kiosk also referres to the shops 
selling out of a window, as I think Martin mentioned it (and the images 
posted by me demonstrated).


We will lose this property when tagging these as shop=news_agent only - 
because building=kiosk is wrong here.


Perhaps that's an additional tag we have to find. I'm not sure.
But it should be considered also in this discussion here.

regards
Peter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?

Antony Pegg anttheli...@gmail.com writes:

 tagging admin area / populated centers / labels in USA seems to come down to
 two main tags:

 admin_level and place

Before you over-simplify, let me point out a couple things:

1. Not all of the US is incorporated.  In the Northeast, every tiny part
of land is incorporated into a town or township or borough.  But in the
Southeast (and I presume elsewhere as well), there's lots of
unincorporated land, even in the vicinity of large cities.  Look at
Atlanta, which still has lots of unincorporated area.

That's a big variation, and the map needs to be equally competent at
handling both regions.

2. Defining how important a city is (and thus, how big its label on
the map should be) is a tricky thing to do.  Population is certainly a
large factor, but how do you define this?  The City of Atlanta is the
#33 most populous city in the US, with 540,000 people, but the Atlanta
metropolitan area is #9 with 5,475,000 people and is the largest metro
area in 800 miles.

There's also a recognition factor... the whole world knows where New
York is and would expect it to be fairly prominent on a map.  Capitol
cities are considered to be important even when they're not very
prominent or populous.  Etc.


It seems to me that admin_level handles the first point, except that 4
levels to cover all of the US doesn't give much granularity.  Maybe we
need to think about using the in-between levels to show more detail?

place= seems to be handling the second point, but not very well.  Should
label sizes really be determined purely by population?  By importance?
What criteria should there be?  I don't think the current scheme of
city/town/whatever is very good, because it's another instance of
hacking a British scheme onto a country with a very different history
and organization.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?

Andrew S. J. Sawyer assaw...@gmail.com writes:

 My thoughts are mixed in below.

 On Wed, Oct 20, 2010 at 11:17, Peter Budny pet...@gatech.edu wrote:

 Antony Pegg anttheli...@gmail.com writes:

  tagging admin area / populated centers / labels in USA seems to
  come down to two main tags:
 
  admin_level and place

 Before you over-simplify, let me point out a couple things:

 1. Not all of the US is incorporated.  In the Northeast, every tiny part
 of land is incorporated into a town or township or borough.  But in the
 Southeast (and I presume elsewhere as well), there's lots of
 unincorporated land, even in the vicinity of large cities.  Look at
 Atlanta, which still has lots of unincorporated area.

 That's a big variation, and the map needs to be equally competent at
 handling both regions.

 Slight correction, not all land in the Northeast is incorporated. In New
 Hampshire there are a handful of communities which are not
 incorporated.

I was exaggerating to illustrate the differences, but point taken.

 2. Defining how important a city is (and thus, how big its label on
 the map should be) is a tricky thing to do.  Population is certainly a
 large factor, but how do you define this?  The City of Atlanta is the
 #33 most populous city in the US, with 540,000 people, but the Atlanta
 metropolitan area is #9 with 5,475,000 people and is the largest metro
 area in 800 miles.

 There's also a recognition factor... the whole world knows where New
 York is and would expect it to be fairly prominent on a map.  Capitol
 cities are considered to be important even when they're not very
 prominent or populous.  Etc.

 It seems to me that admin_level handles the first point, except that 4
 levels to cover all of the US doesn't give much granularity.  Maybe we
 need to think about using the in-between levels to show more detail?

 place= seems to be handling the second point, but not very well.  Should
 label sizes really be determined purely by population?  By importance?
 What criteria should there be?  I don't think the current scheme of
 city/town/whatever is very good, because it's another instance of
 hacking a British scheme onto a country with a very different history
 and organization.

 I agree that there isn't a one-size-fits-all approach that will work
 with displaying/tagging named communities on the map. I think that a
 combination of the size of the given area, the admin_level of the
 given area (country, state, county, etc), population and
 recognizability (capital cities, etc). The latter being the most
 difficult to quantify in a manner in which many people would agree on
 (less capital cities).

I forgot to mention control cities (http://en.wikipedia.org/wiki/Control_city).
These are cities that are designated for use on highway signs to
indicate which direction you're heading.  These should definitely appear
on the map, even if they're relatively small cities (e.g. Valdosta,
Georgia).

 However, I agree that a ratio of area, admin_level and population
 could take care of most cases.

This gets me wondering if maybe there's some way to do it more
automatically.  For instance, it should be easy to find data sources
for population, area, and lists of global cities
(http://en.wikipedia.org/wiki/Global_city) and control cities.  Maybe
there should be a process just before the renderer that takes in that
information and decides how to label cities automatically.  That keeps
the OSM database down to the basics.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?

Richard Weait rich...@weait.com writes:

 On Wed, Oct 20, 2010 at 12:20 PM, Peter Budny pet...@gatech.edu wrote:

 [ ... ]

 I forgot to mention control cities 
 (http://en.wikipedia.org/wiki/Control_city).
 These are cities that are designated for use on highway signs to
 indicate which direction you're heading.  These should definitely appear
 on the map, even if they're relatively small cities (e.g. Valdosta,
 Georgia).

 Control cities for highway destination signs are only important on
 maps for which control cities on highway
 destination signs are important.  Tagging Valdosta as control_city=yes
 might make sense, but tagging it as prominent=yes does not.  Just as
 tagging Athens, GA as 80s_band_origin_city=yes might make sense, but
 tagging it as prominent=yes does not.  Even if you are making a Cities
 of the 80s Bands Map.

 So don't promote Valdosta based on one aspect of the nature of
 Valdosta.  Tell OSM about the nature of Valdosta then render it based
 on the aspects that are important for your audience.  Not everybody
 cares about my band map.  Or your highway control cities.

Totally fair.  I should have written being a control city should be
included as one criterion (of many) to determine whether to label a city
and how big its label should be.  I would definitely support
control_city=yes (or maybe control_city={1-5}, for a bit more
granularity).
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] how to tag US townships?

Alex Mauer ha...@hawkesnest.net writes:

 On 10/20/2010 01:43 PM, M∡rtin Koppenhoefer wrote:
 I guess that Tübingen is more known to the average German then
 Reutlingen, but that's just a guess. As written before, traditionally
 cartographers gave more importance to Tübingen, while in current
 automated internet cartography Tübingen looses almost always against
 Reutlingen. Maybe this is a reflection of a changed interpretation of
 importance but I fear it is simply a loss in quality...

 Probably a bit of both.

 Some more complicated set of heuristics for scoring the prominence of
 a place would definitely be useful here (and everywhere).

 It all depends upon what one wants to emphasise on a map.

 One possible course of action would be to update the renderers to use
 population (or a more complicated system) and then deprecate the
 place=* tag for municipalities.  (place=island and place=islet
 obviously aren’t relevant to this discussion).

 Perhaps we need to shift the discussion to actually figuring out a
 better replacement for place=*?

I think you've hit the nail on the head.  This discussion seems to have
highlighted the inadequacy of place=* for deciding label size and
prominence, since there are so many factors that go in to those
decisions, and the factors change depending on the particular kind of
map you're trying to create.

As complicated as it sounds, I think Martin may be on the right track: a
relation (or node) containing statistics (population, area, number of
universities, number of university students, number of airports, number
of harbors, whether it's a national/state capitol, whether it's a
highway control city, whether it's a global city, etc.) which
renderers can plug in to a formula that will give them a score to
determine how it wants to render each label.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?

Anthony o...@inbox.org writes:

 On Wed, Oct 20, 2010 at 1:21 PM, Jim McAndrew j...@loc8.us wrote:
 There are townships in other states that are managed differently, but in PA
 and NJ, they are just county subdivisions, and are not points to put on a
 map.

 I think you're right here, though I probably would indicate the
 township boundaries on most maps in a similar (though somewhat less
 prominent) manner to county boundaries - at least at certain zoom
 levels.

It sounds like you may have just found a use for the missing
admin_level=7 in the US.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?

Anthony o...@inbox.org writes:

 On Wed, Oct 20, 2010 at 3:49 PM, Peter Budny pet...@gatech.edu wrote:
 Anthony o...@inbox.org writes:

 On Wed, Oct 20, 2010 at 1:21 PM, Jim McAndrew j...@loc8.us wrote:
 There are townships in other states that are managed differently, but in PA
 and NJ, they are just county subdivisions, and are not points to put on a
 map.

 I think you're right here, though I probably would indicate the
 township boundaries on most maps in a similar (though somewhat less
 prominent) manner to county boundaries - at least at certain zoom
 levels.

 It sounds like you may have just found a use for the missing
 admin_level=7 in the US.

 What's wrong with admin_level=8?

According to Wikipedia, many townships are an intermediate form of
government below the county level but above (or sometimes merely
separate from) a city/municipality, although it varies by state (New
Jersey being one of the exceptions).

http://en.wikipedia.org/wiki/Political_divisions_of_the_United_States
#Townships_in_the_United_States

So that would give us

County - admin_level=6
Township (if they exist) - admin_level=7
City/municipality/town/village boundary - admin_level=8

These would apply to the border of the thing, while something else
(probably a relation) would indicate what it is for labelling purposes.
Example: merged city-county governments (Louisville-Jefferson and
Lexington-Fayette, both in Kentucky) would have borders with
admin_level=6 but would be tagged as cities, because they need to have a
dot placed in the city center.  (They would probably /also/ be tagged
with a county relation/tag/whatever.)
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?

Anthony o...@inbox.org writes:

 On Wed, Oct 20, 2010 at 4:10 PM, Alex Mauer ha...@hawkesnest.net wrote:
 On 10/20/2010 03:01 PM, Alex Mauer wrote:

 Townships are at the same level as cities/towns/villages/other
 municipalities[1], [2]. I’m sure someone correct me if I’m wrong, but my
 understanding is you won’t find a chunk of land that is both
 “city|village|etc.” and “township” simultaneously; cities et al. can
 annex portions of townships easily, but they then are no longer part of
 that township.

 Scratch that.  Eleven states allow overlap[1]:

 Indiana, Connecticut, Illinois, Kansas, Michigan, Minnesota, Missouri,
 Nebraska, New York, Ohio, and Vermont

 admin_level=7 it is.

 Only in those 11 states, right?

 I'm surprised admin level isn't already handled defined on a state by
 state level.

No objection from me.  It'll make things a little more complicated, but
it's the best way to match the tags to what they actually represent.
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] how to tag US townships?