Re: [OSM-talk] Tagging schema
Egil Hjelmeland wrote: > OSM is a community of volunteers. So neither bureaucracy or > dictatorship is probably the way to go. I would guess that forking > off a “tagging” mail group with a strict “keep-to-topic” policy > would be the way to proceed. I've asked for a tagging mailing list to be set up and have offered to administrate it. On a more general level, the issue with freeform tags isn't so much that they need replacing per se, but that the documentation, as almost everywhere in OSM, is shockingly bad. When you say "I DO NOT WANT TO SEARCH TALK-MAIL ARCHIVES TO LEARN HOW TO TAG!" that's a failing of the documentation, not of the way in which tags are introduced into circulation. In actual fact we _do_ converge on most tags. This whole yes/true/1 malarkey is no issue at all. foot=yes outnumbers foot=1 by 56610:1 (really), building=yes outnumbers building=true by 135:1, and even with the oneway tag (where '1' has some historical currency because early editors couldn't reverse the direction of a way, so 1/-1 was more common), oneway=yes outnumbers oneway=1 by 10:1. As Matt's graph shows, =yes is increasing in dominance, too. Potlatch has always used =yes and the josm-dev archives suggest that JOSM switched from =true to =yes last year. Pretty much the only significant area of disagreement I can think of right now is footway vs path, and even that's less a confict, more TMTOWTDI. cheers Richard -- View this message in context: http://www.nabble.com/Tagging-schema-tp25743250p25746268.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, October 5, 2009 15:36, Lester Caine wrote:
> ( Egil - a little aside, while a check box for boolean would be nice,
> there is still an element of 'NULL' - that is in addition to setting a
> boolean tag, one still needs to decide if it should or should not be
> present )
Checkboxes these days /can/ represent three states. There are usually two
states: checked (or ticked) and not checked (an empty white box). In most
GUIs it is possible to represent a third state, perhaps a grey square
filling the box. (This is different from the control being disabled,
usually shown by being greyed-out). The meaning of this third state
depends on the application, but it can mean NULL, unknown, conflicting
source data, or whatever you want it to mean when it's not True or False.
I'm not sure that this third state is particularly useful or intuitive,
but I know it means something different to True or False when I see it.
I like the Japanese style of conveying information like this. A cross
('X', often red) means 'no', 'none', 'wrong', 'false', or 'not'. A circle
('O', often green) means 'yes', 'correct', 'available', 'OK', or 'true'.
A triangle (hmm, can't do that in ASCII) means 'maybe', 'limited',
'restricted', 'perhaps'. Obviously their meanings depend on context, but
they are well-known in Japan (and not too confusing outside of Japan).
In fact, here's a handy-dandy reference:
Re: [OSM-talk] SteveC should decide
On Sat, Oct 3, 2009 at 4:24 AM, Russ Nelson wrote: > Matt Amos writes: > > forcing all mappers, editors and renderers to support it? > > Why do people keep saying that I want to use force? From where do > they get this idea? Have I ever suggested the use of force? Gun, > knife, sword, empty hand? Rejection of ill-formed tags at the API? > Please, quote me on it if you think I have. > > > if mappers tag the way they feel is best and the tool authors (i.e: > > nonames layer) consume the tags in the way they feel is best then the > > two will converge, > > Let me propose an alternative course of events which is less > desirable: > > Anyone who asks how to mark a road as having no name is told that > there is no consensus. They might get sent to the Wiki page on it. > That page gives no advice or too much advice. The mapper takes no > action. The database has no tags, the tool authors don't implement > any of them because the data isn't there, and the issue doesn't > converge. > > I point to the +1 year age of the Noname proposal and recent > inactivity and suggest that convergance isn't happening. > > http://wiki.openstreetmap.org/wiki/Proposed_features/Noname > > I suggest instead that in cases such as these, SteveC should bless one > of them with his Holy Water of Antioch (and the number of the tags > shall be 3, no more and no less). His blessing will tip the stable > disconvergance in one direction. As the person whose first came up with a no-names map for London (well, actually it was a named map of London, turned into a nonames map on SteveC's suggestion), I have an *official leadership announcement* to make: There shall be no tagging of unnamed roads. It is not important. They show up on the no-names map -- big deal -- its a mapping aid not a holy grail of "there shall be no highlighted roads". Just deal with it. Right. Done. Now anyone respecting my authority can happily continue with life. I'll leave someone else to document the wiki with my decision. Thanks, Dave PS. I have no idea who does/doesn't agree with me and I've no idea what SteveC thinks about it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Flickr Now Supports OSM Tags
On Sat, Oct 3, 2009 at 4:10 PM, Dave F. wrote: > Dave Stubbs wrote: >> On Thu, Oct 1, 2009 at 12:58 AM, Dave F. wrote: >> >>> Richard Fairhurst wrote: >>> Elizabeth Dodd wrote: > For starters if the maintainers of JOSM Potlatch and Merkaartor encouraged > the use of yes/no it would be a way forward. > > Potlatch does indeed have 'yes' (rather than 'true' or '1') in its presets and autocomplete. cheers Richard >>> Will v2.0 disallow user input altogether & be completely based on 'click >>> to select' presets? >>> >>> >> >> >> Not a chance in hell. >> >> Click "Advanced" at the bottom of the tags section. Oh yes, raw tag >> entry FTW! for when you damn well know the editor is wrong. >> Plus the "presets" (they're not really presets now, but property >> editors) are completely configurable[1], and (once I put the pref box >> in) swappable at run time. >> Oh, and the oneway preset i currently have happily recognises >> 1=true=yes/0=false=no/reverse=-1. It's only when you set it that it >> will standardise to yes/no/-1. >> >> Dave >> >> [1] >> http://trac.openstreetmap.org/browser/applications/editors/potlatch2/resources/map_features.xml >> >> >> > Hi > > 1. Would putting a flag on the raw tag be useful, allowing them to be > easily verified so they conform to the wiki set of tags? No > > 2. When it's rolled out will there be an XML file per editor, which is > stored on their computer or one for everybody? > XML is loaded at runtime. The default will be up to the editor deployer (the editor authorises with OAuth so it does not need to be hosted on OSM itself -- we could for instance host a cycle feature orientated version on opencyclemap.org). It would also be pretty easy to add a user preference to use different XML hosted on any website anywhere, though I would not expect most users to take advantage of this. > 3. Could you explain what a property editor is compared to a preset? Preset kind of implies input only to me. ie: a "Make this a post box" button. A post box has certain other properties and the editor has a dialog box for you to put them in. So you end up with a "Post Box Panel" that the user has to invoke to create or edit post boxes. This is a secondary system to facilitate entering tags. The difference here is that we're trying to make tags the back end stuff that nobody really cares about. Post boxes have certain properties which the XML tells the editor about -- the editor then provides input boxes to the user for these properties. The XML also tells the editor how to recognise a post box so the user never has to do anything special. The user can then view/edit the encoded tags if they want in the same way firefox has a "View Source" option. So from a technical point of view there's very little difference really -- it's just presentation and UI focus. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Andrew Errington wrote: > On Mon, October 5, 2009 15:36, Lester Caine wrote: > >> ( Egil - a little aside, while a check box for boolean would be nice, >> there is still an element of 'NULL' - that is in addition to setting a >> boolean tag, one still needs to decide if it should or should not be >> present ) > > Checkboxes these days /can/ represent three states. There are usually two > states: checked (or ticked) and not checked (an empty white box). In most > GUIs it is possible to represent a third state, perhaps a grey square > filling the box. (This is different from the control being disabled, > usually shown by being greyed-out). The meaning of this third state > depends on the application, but it can mean NULL, unknown, conflicting > source data, or whatever you want it to mean when it's not True or False. > > I'm not sure that this third state is particularly useful or intuitive, > but I know it means something different to True or False when I see it. Your missing the point Andrew - we need to be able to 'switch the tag on or off' as in Add it or not to the current object. We would not expect every 'boolean' tag to be presented, so need to be able to select it, and then also delete it again if appropriate. In my terms 'NULL' just means not present at all, but if it was a tag that has a default interpretation, then it may be added automatically anyway? But need not be present to flag it's default state. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
2009/10/4 Dave F. : > I'd go for b) for all the reasons mentioned above +1 another issue is the size. If you try to do statistics based on the areas of certain landuse, you would want them to be their real size (as precise as possible) and not size= area size - (roadlength of adjacent roads * width * 0,5) as the latter is far more complicated to get. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
I see on exeption though: areas that are pedestrian areas (highway=pedestrian, area=yes). In this case I'd like to connect the pedestrian area (if there is no other limit like a wall, fence, hedge, etc.) to the linear highway (for routing and rendering issues), especially, when the pedestrian area is paved. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 05/10/2009 00:12, Egil Hjelmeland wrote:
> As a mapper, I want a much more structured, well defined tagging scheme.
Steve started a discussion on the dev list in which I proposed just such
a scheme/schema. Since there's been several discussions on talk healding
in this direction, I'll send it here too:
I would like to go further than Steve proposes, but I understand it is a
hard sell to the anarchist wing of OSM while being welcome to the
conformist wing. But I really think what I outline below treads a middle
way. I'm absolutely not proposing to restrict anyone's freedom to add
new tags or values.
I think it would be really helpful to bring together the tag definitions
into one place, *in the database and API itself*. I mean a complete
schema: the tags, their possible values, their descriptions (in multiple
languages), their equivalences both in other languages and synonyms,
their related tags (in essence properties of the main descriptive tag,
hence oneway=... with highway=...), deprecations and so on.
And I think this gets changed as other objects in the database get
changed: freely but consciously. So if there is a new value for shop, it
is a conscious act to add that to the list of values for shop, and to
describe it, not just casually adding it as a tag value.
Let me be quite clear again: this doesn't restrict anyone's freedom to
add new tags or values. Anyone can edit them just like the map data. It
does make it a little more work, but the value of doing so both to the
person making the change and the rest of the community is also increased:
(a) the tag/value is publicised, not buried in the map data, so if it is
a good one, it is more likely to be adopted. For example, take
"landuse=orchard" discussed recently. I've tagged at least three areas
with landuse=orchard in the last 3 years. I just did it. Others may have
used land=orchard, whatever. However, it would only be obvious I'd done
this if the renderers knew about it or I'd made a song and dance about
it. With a central schema, it would automatically be possible for it to
appear on editor menus for example.
(b) if we choose to check data against this schema, spelling mistakes
would be eliminated (not in names and other naturally free form data,
obviously)
(c) editor and consumer programs can all work off the same schema:
presets and menus of values are table driven and in sync, renderers know
the possible things they might want to render (not that they have to of
course) and can see automatically that highway=gate and barrier=gate are
the same thing (or indeed barriere=tor or barrière=porte).
(d) the meaning of newly introduced or changed tags goes along with
them, so that the intention is described to others. Editors can offer
help. Renderers can offer legends.
Here's the kind of thing I had in mind:
* Three new primitives, tagkey for describing the k part of tags,
tagvalue for the v part of tags and tagdescription separated off to
allow for multiple descriptions in multiple languages without having to
download all the data for languages you're not interested in. ("tagkey"
etc can be anything we want, don't get too hung up on the terminology, I
just use it for didactic purposes).
In the following, the fields could be key/value pairs, i.e. tags
themselves, or separate named fields in the database depending on how
things need to be indexed. But allowing the schema to itself have tags
means it is extensible. Perhaps it can even be self-describing.
tagkey
name = [tagkey]
type = text | scalar | real | integer | boolean | value
where...
text: any arbitrary string
scalar: a number possibly qualified by some units
real: a floating point number
integer: an integer
boolean: vlues such as 'yes', 'true', '1', 'no', 'false', '0'
value: a value chosen from among a specific set of strings
documented by the tagvalue object
units = [semicolon separated list of possible units]
defaultunits = [one from the units list]
appliesto = [semicolon separated list of tagkey or tagkey=tagvalue]
indicates this tag is usually used as a property qualifying the
given tags
relevantto = area | node | way | relation
tagvalue
name = [tagvalue]
appliesto = [tagkey]
relevantto = area | node | way | relation
photo[:N] = [url]
synonym = [tagkey or tagkey=tagvalue]
seealso = [tagkey or tagkey=tagvalue]
tagdescription
lang = [languagecode]
appliesto = [tagkey or tagkey=tagvalue]
plus a description in that language (not a tag value)
For example
one or a series
of short posts for excluding or diverting motor vehicles from a road,
lawn, or the like
and so on.
David
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
2009/10/5 Andrew Errington : > On Mon, October 5, 2009 15:36, Lester Caine wrote: > >> ( Egil - a little aside, while a check box for boolean would be nice, >> there is still an element of 'NULL' - that is in addition to setting a >> boolean tag, one still needs to decide if it should or should not be >> present ) > > Checkboxes these days /can/ represent three states. There are usually two > states: checked (or ticked) and not checked (an empty white box). In most > GUIs it is possible to represent a third state, perhaps a grey square > filling the box. (This is different from the control being disabled, > usually shown by being greyed-out). The meaning of this third state > depends on the application, but it can mean NULL, unknown, conflicting > source data, or whatever you want it to mean when it's not True or False. > > I'm not sure that this third state is particularly useful or intuitive, > but I know it means something different to True or False when I see it. in JOSM-Preset there are indeed three states: yes, no and notset. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] footnav: 3D visualisation tool for OSM data: updates
A few updates to "footnav", the 3D OSM visualisation tool aimed at countryside (and eventually mobile, in the field) use. The main development is that it will now read in OSM data and overlay it on the SRTM data, using bilinear interpolation. This mostly works, but there are issues to do with ways "tunnelling through" the terrain, so a more sophisticated algorithm will be needed to ensure that the rendered way always intersects with the edges of the SRTM quadrilaterals. The sourceforge project page is http://footnav.sourceforge.net. Incidentally the sourceforge RSS feed relating to the project seems to be broken, the most recent news is revision 5 on Sep 18th, yet I've made 3 revisions since then, one earlier today. If you go to the SVN repository: http://footnav.svn.sourceforge.net/viewvc/footnav/ you download a .tar.gz file of the source (see bottom of page). The readme file contains info on how to test. As I mentioned before it does need a fast graphics card: performance is reasonably good with a whole .hgt file (1 degree x 1 degree) on a Mac Book Pro with Nvidia 9400 running Ubuntu 9.04. Performance under OS X 10.5 is actually slower than under Linux... so much for Apple optimising their OS for the hardware, and the Ubuntu wiki saying you have to re-compile the kernel to get the most out of the graphics card! It's not tested under Windows but ought to work. Incidentally I'm wondering if it would be a good idea to have an "apps" OSM mailing list where people can announce updates to apps using OSM data, and discuss development of such apps. Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
Martin Koppenhoefer wrote: > I see on exeption though: areas that are pedestrian areas > (highway=pedestrian, area=yes). In this case I'd like to connect the > pedestrian area (if there is no other limit like a wall, fence, hedge, > etc.) to the linear highway (for routing and rendering issues), > especially, when the pedestrian area is paved. This is an area of micromapping that DOES need to have some 'guidelines' so that it can actually be rendered, and routing software can route for pedestrians. Footpaths around here can take many paths, following the field boundaries rather than the road - with a wide grass verge, being absent altogether with high hedges lining the sides of a single track road, with fields on the other side, or present in either side of a road but with wide verges ( which may or may not be usable to walk on - these can be steeply banked to prevent 'traveler' camping ), with fields beyond. At a macro level - foot=yes against the vehicle route may be 'nominally' correct, but the real route may require some more detail to add safe pedestrian instructions such as - 'cross to footpath on other side of road'. The field boundaries, and ramblers paths that they follow instead of the roadway need to be consistently tagged? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
2009/10/5 Egil Hjelmeland : > Every key should be assigned a type (or class). Could be: > > - boolean > - enumeration > - numeric > - string > - free text. > > Boolean is yes/no. Editor tools should present a Boolean key as a checkbox. there is IMHO no boolean values in OSM. Feel free to give counter examples. Highways (I guess you're talking about ref-tag) aren't enumerated either (they used to be dependant on national enumeration, but nowadays there is even official refs like "SP ex SS 527"). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Updating a point of interest
2009/10/5 John F. Eldredge : > I was examining the map for the part of town where I work, and noticed that a > former hospital (now commercial offices) was still labeled as a hospital. > Google Maps, Yahoo Maps, and Blackberry Maps have that same out-of-date > information. What would be the best way to note that the former hospital is > no longer a hospital, so that no one will mistakenly go there in a medical > emergency? remove the hospital-tag and set a commercial-building tag. Probably add a tag note="former hospital, converted to office-building in 2001" cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
> I'm seeking advice as to best practice in the following type of situation: > > As an increasingly common example, now that people are getting around to > mapping areas such as leisure=, natural= and landuse= ... > > Consider the case of landuse=farm on one side of a highway (say a > secondary road) and leisure=golf_course on the other side of the highway. The > easiest way to map this - and the one usually adopted it seems - is to make > the > boundaries of the farm and the golf course both coterminous with the > highway so that the three lines are superimposed in the editors (not quite > sure > how the various renderers handle this) and the representation of the highway > has zero width. > > There are, however, potential problems with this (quite apart from the > slightly clumsy editing when several ways are superimposed) where detailed > mapping would ideally show that in real life the golf course and the farm do > not in fact have a common boundary but both are, for example, separated by > hedges (which may or may not be mapped) from the road. > > It is clearly possible to map the farm and the golf course as separated > areas with the road mapped as a line drawn between them - i.e. the mapping > has three separate parallel lines. This assists with mapping more clearly > features such as junctions of paths with the road (and stiles on paths at such > junctions). But is this unduly messy or does it create rendering issues > (e.g. if the lines are not absolutely parallel and just far enough apart to > render with random gaps between, say, the golf course and the road. > > The situation is even trickier where, say, a farm has been mapped as a > single area (same land use) with, say, a road crossing it - whereas in > practice, this is two separate farms - one on each side of the road - that > may at > some stage need to be named separately. Then we have to go back and split > the area, etc. > > This seems to be a quite a generic issue and I am wondering how people see > the pros and cons of (a) the simple approach with coterminous lines giving > a notional zero width to the highway, vs. (b) the more precise approach of > mapping the areas either side of the highway as areas that are separate > both from each other and from the highway. > > In practice, almost all mapping seems to use approach (a) - but would > approach (b) be easier for subsequent editing and addition of detail, and > rather clearer as it avoids superimposed ways and potential editing errors? > > Views? IMO (a) is the correct way to do this. We are trying to represent reality in our database. In order to achieve this, certain abstractions are necessary. For a road, we can either choose to map it as a linear object (this is the common case), or we can map its geometry more exactly by using an area. In both cases, however, the object in our database represents the entire road (i.e. not only the middle line). Because in reality, there is no gap between the road and the areas next to it, there shouldn't be one in the database either. In other words, we should keep the topology intact, even if we choose to simplify the geometry. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
David Earl frankieandshadow.com> writes: >I think it would be really helpful to bring together the tag definitions >into one place, *in the database and API itself*. I mean a complete >schema: the tags, their possible values, their descriptions (in multiple >languages), their equivalences both in other languages and synonyms, >their related tags (in essence properties of the main descriptive tag, >hence oneway=... with highway=...), deprecations and so on. +1. >And I think this gets changed as other objects in the database get >changed: freely but consciously. So if there is a new value for shop, it >is a conscious act to add that to the list of values for shop, and to >describe it, not just casually adding it as a tag value. Ideally, there would be some kind of prompt or reminder: you recently tagged a node with shop=antiques; if this was intentional, please go to whatever/tags/shop and add the new value with a description. Or, you recently tagged a node with shop=literature, but the database (visible at whatever/tags/shop/literature) suggests that this is deprecated in favour of shop=bookshop. Perhaps you would like to change it? -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 5 Oct 2009, Martin Koppenhoefer wrote: > there is IMHO no boolean values in OSM. Feel free to give counter > examples. The arguments for how to tag a footway and a cycleway contain a number of boolean examples. Either you are permitted to drive a car down the footway, or you are not. You are permitted to cycle on the footway, or you are not. The trinary response from my culture would be "it's only a problem if you are caught". no_exit is boolean until we consider flying as a possibility and the tags needed for certain Australian road conditions dry_weather_only and 4wd_only are certainly boolean. so having dealt with boolean, and discussed enumeration (house numbers) do you have any further suggestions after numeric, string and free text? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC should decide
2009/10/4 Russ Nelson : ...that he's conducting bizarre breeding > experiments on cute little animals. Basically, SteveC doesn't find > this teasing at all funny. what's this breeding stuff about? Can anyone point to a relevant page? Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
David Earl wrote:
> I think it would be really helpful to bring together the tag definitions
> into one place, *in the database and API itself*. I mean a complete
> schema: the tags, their possible values, their descriptions (in multiple
> languages), their equivalences both in other languages and synonyms,
> their related tags (in essence properties of the main descriptive tag,
> hence oneway=... with highway=...), deprecations and so on.
>
> And I think this gets changed as other objects in the database get
> changed: freely but consciously. So if there is a new value for shop, it
> is a conscious act to add that to the list of values for shop, and to
> describe it, not just casually adding it as a tag value.
+100%
> Let me be quite clear again: this doesn't restrict anyone's freedom to
> add new tags or values. Anyone can edit them just like the map data. It
> does make it a little more work, but the value of doing so both to the
> person making the change and the rest of the community is also increased:
Until such time as agreement is made to restrict some tags, there is
nothing to stop free format text as at present, but having a list of
agreed values - and presenting them in the correct local language - can
only be a good thing?
> (a) the tag/value is publicised, not buried in the map data, so if it is
> a good one, it is more likely to be adopted. For example, take
> "landuse=orchard" discussed recently. I've tagged at least three areas
> with landuse=orchard in the last 3 years. I just did it. Others may have
> used land=orchard, whatever. However, it would only be obvious I'd done
> this if the renderers knew about it or I'd made a song and dance about
> it. With a central schema, it would automatically be possible for it to
> appear on editor menus for example.
Using an agreed set of landuse tags and having on-line links to help
relating to the values makes sense, and again they an be mapped
internally to other languages
> (b) if we choose to check data against this schema, spelling mistakes
> would be eliminated (not in names and other naturally free form data,
> obviously)
Behind the scenes local language tags can be added automatically.
> (c) editor and consumer programs can all work off the same schema:
> presets and menus of values are table driven and in sync, renderers know
> the possible things they might want to render (not that they have to of
> course) and can see automatically that highway=gate and barrier=gate are
> the same thing (or indeed barriere=tor or barrière=porte).
My own preference internally would be for simple numeric tags - but then
I work in 'real' relational databases where mapping appropriate text
when displaying the user view is natural. XML is not really designed
with language translation in mind :(
> (d) the meaning of newly introduced or changed tags goes along with
> them, so that the intention is described to others. Editors can offer
> help. Renderers can offer legends.
And rendering rules could be enhanced by being able to select the
preferred elements that a particular map requires.
> Here's the kind of thing I had in mind:
>
> * Three new primitives, tagkey for describing the k part of tags,
> tagvalue for the v part of tags and tagdescription separated off to
> allow for multiple descriptions in multiple languages without having to
> download all the data for languages you're not interested in. ("tagkey"
> etc can be anything we want, don't get too hung up on the terminology, I
> just use it for didactic purposes).
>
> In the following, the fields could be key/value pairs, i.e. tags
> themselves, or separate named fields in the database depending on how
> things need to be indexed. But allowing the schema to itself have tags
> means it is extensible. Perhaps it can even be self-describing.
>
> tagkey
>name = [tagkey]
>type = text | scalar | real | integer | boolean | value
> where...
> text: any arbitrary string
> scalar: a number possibly qualified by some units
> real: a floating point number
> integer: an integer
> boolean: vlues such as 'yes', 'true', '1', 'no', 'false', '0'
> value: a value chosen from among a specific set of strings
> documented by the tagvalue object
>units = [semicolon separated list of possible units]
>defaultunits = [one from the units list]
>appliesto = [semicolon separated list of tagkey or tagkey=tagvalue]
> indicates this tag is usually used as a property qualifying the
> given tags
>relevantto = area | node | way | relation
>
> tagvalue
>name = [tagvalue]
>appliesto = [tagkey]
>relevantto = area | node | way | relation
>photo[:N] = [url]
>synonym = [tagkey or tagkey=tagvalue]
>seealso = [tagkey or tagkey=tagvalue]
>
> tagdescription
>lang = [languagecode]
>appliesto = [tagkey or tagkey=tagvalue]
>plus a de
Re: [OSM-talk] Tagging schema
2009/10/5 Liz : > On Mon, 5 Oct 2009, Martin Koppenhoefer wrote: >> there is IMHO no boolean values in OSM. Feel free to give counter >> examples. > > The arguments for how to tag a footway and a cycleway contain a number of > boolean examples. > Either you are permitted to drive a car down the footway, or you are not. > You are permitted to cycle on the footway, or you are not. > > The trinary response from my culture would be "it's only a problem if you are > caught". > > no_exit is boolean until we consider flying as a possibility still there are other values like "unknown" and "motor_vehicle" which seem to make sense to me (I didn't add them myself, as I consider noexit (no_exit is used just 5 times, so I guess we're talking about noexit) pointless: that's what a map is for, a router won't need this tag, and in the end the whole earth is noexit, until we consider rockets or other spacecraft a possibility) > so having dealt with boolean, and discussed enumeration (house numbers) > do you have any further suggestions after numeric, string and free text? even housenumbers can be all kind of weird numbers, so limiting the possibilities doesn't really meet the needs. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On 05/10/2009 11:43, Lester Caine wrote: > Rather than all these separate elements, tag values should form part of > the tagkey object, and descriptions can be added at any level. I need to > find the link to a good example, but > > > > > > one or a series > of short posts for excluding or diverting motor vehicles from a > road, lawn, or the like > > > But I suspect this is just a misunderstanding, as a scheme needs to be > defined in .xsl. > http://www.cabinetoffice.gov.uk/media/260545/BuildingStructure.xml is a > good example of a definition of a building with enumerated tag values. I > was trying to find the one that goes with 'landuse' but I don't have > time ... need to be on the road by 1 ... You're probably right - this was only a first attempt at suggesting the principle. In practice, the actual representation would be as database tables, and this gets exposed through the API as XML. I would think the values would typically be in a separate table, which is why I wrote it the way I did, but the API doesn't have to deliver it separately as I wrote it. I think you'd still want to be able to filter descriptions and possibly other aspects by selected language to limit the size, but that's a minor detail. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
David Earl wrote: > On 05/10/2009 11:43, Lester Caine wrote: >> Rather than all these separate elements, tag values should form part >> of the tagkey object, and descriptions can be added at any level. I >> need to find the link to a good example, but >> >> >> >> >> >> one or a series >> of short posts for excluding or diverting motor vehicles from a >> road, lawn, or the like >> >> >> But I suspect this is just a misunderstanding, as a scheme needs to be >> defined in .xsl. >> http://www.cabinetoffice.gov.uk/media/260545/BuildingStructure.xml is >> a good example of a definition of a building with enumerated tag >> values. I was trying to find the one that goes with 'landuse' but I >> don't have time ... need to be on the road by 1 ... > > You're probably right - this was only a first attempt at suggesting the > principle. > > In practice, the actual representation would be as database tables, and > this gets exposed through the API as XML. I would think the values would > typically be in a separate table, which is why I wrote it the way I did, > but the API doesn't have to deliver it separately as I wrote it. > > I think you'd still want to be able to filter descriptions and possibly > other aspects by selected language to limit the size, but that's a minor > detail. If one ignores the 'XML' then things are very much easier, and yes there would be table for 'descriptions', with a language flag as well as the 'id' for the description. Lookup would return a selected language or English if there is no alternative. THIS table would simply be used by anything that need to return a text string - and needs it translating - not just descriptions ;) I think though - we need to define a proper xsl schema wjich can be used WITH the tag data :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
> And I think this gets changed as other objects in the database get > changed: freely but consciously. So if there is a new value for shop, it > is a conscious act to add that to the list of values for shop, and to > describe it, not just casually adding it as a tag value. > > Let me be quite clear again: this doesn't restrict anyone's freedom to > add new tags or values. Anyone can edit them just like the map data. It > does make it a little more work, but the value of doing so both to the > person making the change and the rest of the community is also increased: > (a) the tag/value is publicised, not buried in the map data, so if it is > a good one, it is more likely to be adopted I recently set out to do an all-inclusive map of a section of town. Perhaps I'm unfortunate enough to live in a city of lawyers, but it seems that a large entire section of town consists of law offices.I can't believe I'm not the first person to want to tag a law office as a shop category (I may have completely missed an existing tag). The process of creating a new tag is laborious: Search the wiki for approved tags that don't appear in presets Search the wiki for a proposed tag to be able to at least choose a more common tag Search TagWatch - I didn't play with this for long, but the links from the wiki to TagWatch don't make it easy to query a list of tags in use for key shop for example. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 05 Oct 2009 12:25:37 +0100 Lester Caine wrote: > I think though - we need to define a proper xsl schema wjich can > be used WITH the tag data :( > OK, benefit of the doubt goes out the window at this point. If you are going to say you hate XML with any credibility, you need to know that there is no such thing as an "XSL schema". Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
> For a road, we can either choose to map it as a linear object (this is the > common case), or we can map its geometry more exactly by using an area. In > both cases, however, the object in our database represents the entire road > (i.e. not only the middle line). Because in reality, there is no gap between > the road and the areas next to it, there shouldn't be one in the database > either. > > In other words, we should keep the topology intact, even if we choose to > simplify the geometry. This would be hard to do properly render in the renderers, as they will render the road with non-zero width and to render things correctly, they should "push" the boundaries of touching landuses so they will touch the rendered road borders. It is IMHO easier to learn renderers to support proper width tag and add that tag to the street between. With proper micro-mapping, even the street between could be mapped as an area, but that could be perhaps a bit too much of detail. But a) could be used as acceptable temporary solution until someone with better information (like having aerial photography) remaps it as b) Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 05 Oct 2009 01:12:41 +0200 Egil Hjelmeland wrote: > I started mapping my local mountain village in Norway a month ago. I > find the fundamental OSM data model very simple and elegant: The > three basic elements (node, way/area, relation), and properties as > key-value pairs. But I don’t like that free-form tagging has been > elevated to a Religion. > > As a mapper, I want a much more structured, well defined tagging > scheme. > I'm late saying this. I think your proposal is thorough, workable and well stated. Thank you – you went to places I am afraid to even dare think, so inculcated am I. I am not sure I have seen anything compelling in the thread to challenge or add to what you have said. I'm afraid I have nothing to add but support because it's exactly what I would like to see happen. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
> > For a road, we can either choose to map it as a linear object (this is > the common case), or we can map its geometry more exactly by using an area. > In both cases, however, the object in our database represents the entire > road (i.e. not only the middle line). Because in reality, there is no gap > between the road and the areas next to it, there shouldn't be one in the > database either. > > > > In other words, we should keep the topology intact, even if we choose > to simplify the geometry. > > This would be hard to do properly render in the renderers, as they > will render the road with non-zero width and to render things > correctly, they should "push" the boundaries of touching landuses so > they will touch the rendered road borders. > > It is IMHO easier to learn renderers to support proper width tag and > add that tag to the street between. > > With proper micro-mapping, even the street between could be mapped as > an area, but that could be perhaps a bit too much of detail. > > But a) could be used as acceptable temporary solution until someone > with better information (like having aerial photography) remaps it as > b) Yes, this is basically what I wanted to say. Leave it to the mappers whether they want to use a way or an area for a road. But with option (b) and a linear way you would have a gap next to the road. In the case of landuse, this is not a problem in practice, but if there is a place, there you need to insert artificial ways that are not there in reality, just to get the connectivity between the two objects: http://osm.org/go/0JUKytHID-- -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
2009/10/5 "Marc Schütz" : >> But a) could be used as acceptable temporary solution until someone >> with better information (like having aerial photography) remaps it as >> b) > > Yes, this is basically what I wanted to say. Leave it to the mappers whether > they want to use a way or an area for a road. it will be much harder to add this detail, if all areas are merged though. > But with option (b) and a linear way you would have a gap next to the road. > In the case of landuse, this is not a problem in practice, but if there is a > place, there you need to insert artificial ways that are not there in > reality, just to get the connectivity between the two objects: > http://osm.org/go/0JUKytHID-- which objects are you referring to? parkings usually have those ways (for crossing the sidewalk) so they won't be artificial, and pedestrian areas are the exception I mentioned above. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC should decide
On Mon, Oct 5, 2009 at 11:33 AM, Martin Koppenhoefer wrote: > 2009/10/4 Russ Nelson : > ...that he's conducting bizarre breeding >> experiments on cute little animals. Basically, SteveC doesn't find >> this teasing at all funny. > > what's this breeding stuff about? Can anyone point to a relevant page? it's just a little in-joke. http://lists.openstreetmap.org/pipermail/legal-talk/2009-March/002236.html cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
On Mon, Oct 5, 2009 at 6:18 AM, "Marc Schütz" wrote: > For a road, we can either choose to map it as a linear object (this is the > common case), or we can map its geometry more exactly by using an area. In > both cases, however, the object in our database represents the entire road > (i.e. not only the middle line). Because in reality, there is no gap between > the road and the areas next to it, there shouldn't be one in the database > either. > 1) That's not always true. There is often a gap between "the road" and the areas next to it. In fact, I can't think of a single road which doesn't have at least some gap (say, a curb) between "the road" and the other area (though I'm sure someone can come up with a counterexample). 2) If you have two buildings which are directly next to each other and touching, and you represent them as points in order to map the address information, should you use only one point, since they're touching? On Mon, Oct 5, 2009 at 8:39 AM, MP wrote: > With proper micro-mapping, even the street between could be mapped as > an area, but that could be perhaps a bit too much of detail. > I don't know about the "street", but I don't think it's too much to map the right of way as a boundary relation. This would be *in addition* to mapping the ways, as it is something that currently isn't being mapped but would provide useful information if it were. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Turn restrictions
Hi, I have one question for turn restrictions gurus :) Have you used http://keepright.ipax.at site for error checking? I got a message that turn restriction has no type tag. I have used wiki for getting to know how to use turn restrictions, and there the examples given on the page: http://wiki.openstreetmap.org/wiki/Relation:restriction type tag is not used. The relation in question is: http://www.openstreetmap.org/browse/relation/187464 I added type=restriction to it now, but is is necessary or not? Should the wiki be updated? Cheers, Valent. -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, msn: valent.turko...@hotmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC should decide
russ and i had a useful chat on IRC late last night and i think we've cleared up the misunderstanding that lies at the root of this thread. (russ - please correct me if i've misreported anything here). apologies to anyone who's getting really tired of this thread. hopefully we're at or near the end now. On 10/4/09, Russ Nelson wrote: > > you asked why people are thinking that you're in favour of people > > being told what to do. your answer appears to confirm that, yes; > > you're in favour of people being told what to do. > > It appears to me as if your "being told what to do" should be > interpreted as coercion, but I've repeatedly said that leadership in a > voluntary organization is not coercion. How many times do I have to > tell you that it's NOT POSSIBLE TO COERCE VOLUNTEERS Why do I > have to shout to be heard? the misunderstanding here came from different interpretations of the word "decide". my reading of it was the meaning "final, authoritative judgement", but russ' intended meaning was different, something more like "give advice, and have it listened-to" (my words). for this definition of "decide" i'm in complete agreement with russ; steve should be able to give advice and have it listened to. russ had some good guidelines for appropriately resolving tagging debates (slightly paraphrased): 1) if it's an issue where the community hasn't been able to decide, they might need a decision/advice. 2) if one of the schemas preserves enough information to be transformed into the others at some future date, use that one. 3) it's better to keep mapping and tagging than argue about tagging. there was some discussion of whether voting is a good way of resolving anything. but that's a whole other debate, which i'd rather leave for another day ;-) cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
Original-Nachricht > Datum: Mon, 5 Oct 2009 15:28:54 +0200 > Von: Martin Koppenhoefer > An: "Marc Schütz" > CC: MP , talk@openstreetmap.org > Betreff: Re: [OSM-talk] Landuse areas etc. abutting highways > 2009/10/5 "Marc Schütz" : > >> But a) could be used as acceptable temporary solution until someone > >> with better information (like having aerial photography) remaps it as > >> b) > > > > Yes, this is basically what I wanted to say. Leave it to the mappers > whether they want to use a way or an area for a road. > > it will be much harder to add this detail, if all areas are merged though. Not really. JOSM supports disconnecting ways since a long time now. But anyway: doing things wrong just to make editing easier is not a good thing. > > > But with option (b) and a linear way you would have a gap next to the > road. In the case of landuse, this is not a problem in practice, but if there > is a place, there you need to insert artificial ways that are not there in > reality, just to get the connectivity between the two objects: > > http://osm.org/go/0JUKytHID-- > > which objects are you referring to? parkings usually have those ways > (for crossing the sidewalk) so they won't be artificial, and > pedestrian areas are the exception I mentioned above. Look at the google sat image: http://maps.google.com/maps?f=q&source=s_q&hl=de&geocode=&q=bayreuth&sll=37.0625,-95.677068&sspn=59.856937,107.138672&ie=UTF8&hq=&hnear=Bayreuth,+Bayern,+Deutschland&ll=49.946316,11.577148&spn=0.000754,0.001635&t=k&z=20 As you can see, there are no ways between the road and the plaza on the left side. But there are in the database (e.g. the one at the end of Alexanderstraße). This is an ugly hack to reenable routing, which was broken by letting the plaza end before the street. (And I don't even want to start about the situation on the other side of the road.) Mapping it the way it is done there does not really make sense: Either the exact geometry is important for you, then you should convert both the plaza and the road to areas. Or it isn't, but then there shouldn't be a problem with extending the plaza so that it borders to the road. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions
Valent Turkovic wrote: > I have used wiki for getting to know how to use turn restrictions, and > there the examples given on the page: > http://wiki.openstreetmap.org/wiki/Relation:restriction > type tag is not used. The type tag is listed in the tags section on that page. The examples were added later - http://wiki.openstreetmap.org/index.php?title=Relation%3Arestriction&diff=216338&oldid=216003 - and it's likely that the type tag was simply forgotten because the examples were primarily intended to demonstrate usage of no_* and only_* tags. > I added type=restriction to it now, but is is necessary or not? Should > the wiki be updated? Imo: Yes, it is necessary (other tools such as JOSM expect it, too), and the examples should be updated to reflect this. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] EGNOS
I'm sure EGNOS is something else other than the new Euro GPS system, but I can't for the life of me remember what, something to do with food and Christmas rings a bell but I can't think what. Anyway so EGNOS is now available for use. So what new things can we do with this new available accuracy, and which devices are EGNOS compatible Oh and is it going to achieve what they way it will or is it going to be a bit of a flop. Oh and I spose the best question If I have an EGNOS GPS can I actual use the data on OSM or is there some copyright stopping me. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Peter Childs wrote: > I'm sure EGNOS is something else other than the new Euro GPS system, > but I can't for the life of me remember what, something to do with > food and Christmas rings a bell but I can't think what. > > Anyway so EGNOS is now available for use. > > So what new things can we do with this new available accuracy, and > which devices are EGNOS compatible Oh and is it going to achieve > what they way it will or is it going to be a bit of a flop. > > Oh and I spose the best question If I have an EGNOS GPS can I actual > use the data on OSM or is there some copyright stopping me. Chances are if your device supports it you've been using it for months anyway. It's been available for *AGES*. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
EGNOS is just another SBAS (Satellite Based Augmentation System), and with EGNOS 100% active we now have tree such systems, including the wider known north american WAAS. I hope more such systems can be available soon, knowing that India and China also are developing similar systems, and there is one active over Japan, which also are developing a different system. Such system is very needed in the equatorial regions where atmospheric disturbance such as scintillation and plasma-bubble effects are more active and can render a handheld GPS completely useless at times, but unfortunately most countries suffering from these effects don't have the funds for such a project. Next milestone in GPS (or I should say GNSS) accuracy will be the activation of Galileo, the European equivalent to GPS. A handheld dual GPS/Galileo receiver with active SBAS will give you an accuracy you never have seen in a small unit, you can almost compete with professional units such as those used in land survey and in the oil industry. BTW: GLONASS is also getting more satellites activated, so that is almost a reliable alternative to GPS while we wait for Galileo, and the chinese plan to activate their COMPASS about same time as Galileo. brgds Aun Johnsen On 05/10/2009, at 11:15, Peter Childs wrote: > I'm sure EGNOS is something else other than the new Euro GPS system, > but I can't for the life of me remember what, something to do with > food and Christmas rings a bell but I can't think what. > > Anyway so EGNOS is now available for use. > > So what new things can we do with this new available accuracy, and > which devices are EGNOS compatible Oh and is it going to achieve > what they way it will or is it going to be a bit of a flop. > > Oh and I spose the best question If I have an EGNOS GPS can I actual > use the data on OSM or is there some copyright stopping me. > > Peter > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
brgds Aun Johnsen On 05/10/2009, at 11:30, Jon Stockill wrote: > Peter Childs wrote: >> I'm sure EGNOS is something else other than the new Euro GPS system, >> but I can't for the life of me remember what, something to do with >> food and Christmas rings a bell but I can't think what. >> >> Anyway so EGNOS is now available for use. >> >> So what new things can we do with this new available accuracy, and >> which devices are EGNOS compatible Oh and is it going to achieve >> what they way it will or is it going to be a bit of a flop. >> >> Oh and I spose the best question If I have an EGNOS GPS can I actual >> use the data on OSM or is there some copyright stopping me. > > Chances are if your device supports it you've been using it for months > anyway. It's been available for *AGES*. > > Jon > It have been available, but officially in a testing phase. According to sources I have it was completely unreliable and destructive until late 2006, after that it tested reliability and accuracy improvements. The latest news is that testing is finally over and the system is classified as operative. > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Hmm. I've been happily using it for the past couple of years, on my Garmin Legend Cx. I can get about 2m stated accuracy when it's working. Though you're right - it's just been officially announced Ready for Use. And it's not the new Euro GPS system - that's Galileo. It's an accuracy augmenter (put badly, but you know what I mean) You need to switch it on in the options - look for something about WAIS or differential GPS. You can tell when it's working as some of the satellite reception bars will have a capital D above them. You'll only have access if you have a clear view of certain geostationary satellites, so it won't always be there. No - there's no reason you can't use it for OSM. PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] On Behalf Of Peter Childs Sent: 05 October 2009 15:15 To: OSM-Talk Subject: [OSM-talk] EGNOS I'm sure EGNOS is something else other than the new Euro GPS system, but I can't for the life of me remember what, something to do with food and Christmas rings a bell but I can't think what. Anyway so EGNOS is now available for use. So what new things can we do with this new available accuracy, and which devices are EGNOS compatible Oh and is it going to achieve what they way it will or is it going to be a bit of a flop. Oh and I spose the best question If I have an EGNOS GPS can I actual use the data on OSM or is there some copyright stopping me. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Please Note: Any views or opinions are solely those of the author and do not necessarily represent those of Independent Television News Limited unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@itn.co.uk Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
You're thinking of eggnog - assuming you weren't joking. PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] On Behalf Of Peter Childs Sent: 05 October 2009 15:15 To: OSM-Talk Subject: [OSM-talk] EGNOS I'm sure EGNOS is something else other than the new Euro GPS system, but I can't for the life of me remember what, something to do with food and Christmas rings a bell but I can't think what. Anyway so EGNOS is now available for use. So what new things can we do with this new available accuracy, and which devices are EGNOS compatible Oh and is it going to achieve what they way it will or is it going to be a bit of a flop. Oh and I spose the best question If I have an EGNOS GPS can I actual use the data on OSM or is there some copyright stopping me. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Please Note: Any views or opinions are solely those of the author and do not necessarily represent those of Independent Television News Limited unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@itn.co.uk Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
2009/10/5 "Marc Schütz" : >> 2009/10/5 "Marc Schütz" : >> >> But a) could be used as acceptable temporary solution until someone >> >> with better information (like having aerial photography) remaps it as >> >> b) >> > >> > Yes, this is basically what I wanted to say. Leave it to the mappers >> whether they want to use a way or an area for a road. >> >> it will be much harder to add this detail, if all areas are merged though. > > Not really. JOSM supports disconnecting ways since a long time now. But > anyway: doing things wrong just to make editing easier is not a good thing. +1. That's why adjacent landuses (see topic) shouldn't be extented to the center of the road. >> > But with option (b) and a linear way you would have a gap next to the >> road. In the case of landuse, this is not a problem in practice, but if there >> is a place, there you need to insert artificial ways that are not there in >> reality, just to get the connectivity between the two objects: >> > http://osm.org/go/0JUKytHID-- >> >> which objects are you referring to? parkings usually have those ways >> (for crossing the sidewalk) so they won't be artificial, and >> pedestrian areas are the exception I mentioned above. > > Look at the google sat image: > http://maps.google.com/maps?f=q&source=s_q&hl=de&geocode=&q=bayreuth&sll=37.0625,-95.677068&sspn=59.856937,107.138672&ie=UTF8&hq=&hnear=Bayreuth,+Bayern,+Deutschland&ll=49.946316,11.577148&spn=0.000754,0.001635&t=k&z=20 That's the mentioned pedestrian area. I agree with you here. > Mapping it the way it is done there does not really make sense: Either the > exact geometry is important for you, then you should convert both the plaza > and the road to areas. Or it isn't, but then there shouldn't be a problem > with extending the plaza so that it borders to the road. +1. but that's still pedestrian areas / highway areas. In these cases the areas _do_ connect to the road. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Barnett, Phillip wrote: > You can tell when it's working as some of the satellite reception bars will > have a capital D above them. > Is that correct? I sometimes get the D's displaying even if I have no reception (no bar showing). I've got a Garmin GPSmap 60C. Any body else get that quirk? Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Yes, I get it sometimes. I guess the GPS receiver is trying to tell you that you are picking up the geostationary satellite that's transmitting corrections, and that IF you were picking up a GPS satellite that is theoretically available according to the downloaded ephemeris (but you're not actually picking up because of trees etc) then you'd be getting differential measurements off it. That's just a guess - it's a while since I looked at this last so my memory may be wrong. PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] On Behalf Of Dave F. Sent: 05 October 2009 16:05 Cc: OSM-Talk Subject: Re: [OSM-talk] EGNOS Barnett, Phillip wrote: > You can tell when it's working as some of the satellite reception bars will > have a capital D above them. > Is that correct? I sometimes get the D's displaying even if I have no reception (no bar showing). I've got a Garmin GPSmap 60C. Any body else get that quirk? Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Please Note: Any views or opinions are solely those of the author and do not necessarily represent those of Independent Television News Limited unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@itn.co.uk Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
2009/10/5 Dave F. : > Barnett, Phillip wrote: >> You can tell when it's working as some of the satellite reception bars will >> have a capital D above them. >> > Is that correct? > I sometimes get the D's displaying even if I have no reception (no bar > showing). > I've got a Garmin GPSmap 60C. Any body else get that quirk? this unit (60 C) supports DGPS according to Garmin manual (DGPS is not available in later GPSs like 60CSx). Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Martin Koppenhoefer wrote: > 2009/10/5 Dave F. : > >> Barnett, Phillip wrote: >> >>> You can tell when it's working as some of the satellite reception bars will >>> have a capital D above them. >>> >>> >> Is that correct? >> I sometimes get the D's displaying even if I have no reception (no bar >> showing). >> I've got a Garmin GPSmap 60C. Any body else get that quirk? >> > > this unit (60 C) supports DGPS according to Garmin manual (DGPS is not > available in later GPSs like 60CSx). > > Martin > > > Correct me if I'm wrong, but I thought DGPS was superseded by WAAS. The software has a WAAS enabled option, but they just didn't update the D to a W. Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
2009/10/5 Dave F. : > Martin Koppenhoefer wrote: >> 2009/10/5 Dave F. : >> >>> Barnett, Phillip wrote: >>> You can tell when it's working as some of the satellite reception bars will have a capital D above them. >>> Is that correct? >>> I sometimes get the D's displaying even if I have no reception (no bar >>> showing). >>> I've got a Garmin GPSmap 60C. Any body else get that quirk? >>> >> >> this unit (60 C) supports DGPS according to Garmin manual (DGPS is not >> available in later GPSs like 60CSx). >> > Correct me if I'm wrong, but I thought DGPS was superseded by WAAS. The > software has a WAAS enabled option, but they just didn't update the D to > a W. don't know what superseded means, but DGPS is not WAAS/EGNOS. Read Wikipedia for more info. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Strictly true, but effectively they're the same, except for the delivery mechanism for broadcasting differential corrections - groundbased UHF radio for DGPS and geostationary satellite broadcast for WAAS/EGNOS. The D symbol just shows that differential readings are being received. PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] On Behalf Of Martin Koppenhoefer Sent: 05 October 2009 17:32 To: Dave F. Cc: OSM Talk Subject: Re: [OSM-talk] EGNOS 2009/10/5 Dave F. : > Martin Koppenhoefer wrote: >> 2009/10/5 Dave F. : >> >>> Barnett, Phillip wrote: >>> You can tell when it's working as some of the satellite reception bars will have a capital D above them. >>> Is that correct? >>> I sometimes get the D's displaying even if I have no reception (no bar >>> showing). >>> I've got a Garmin GPSmap 60C. Any body else get that quirk? >>> >> >> this unit (60 C) supports DGPS according to Garmin manual (DGPS is not >> available in later GPSs like 60CSx). >> > Correct me if I'm wrong, but I thought DGPS was superseded by WAAS. The > software has a WAAS enabled option, but they just didn't update the D to > a W. don't know what superseded means, but DGPS is not WAAS/EGNOS. Read Wikipedia for more info. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Please Note: Any views or opinions are solely those of the author and do not necessarily represent those of Independent Television News Limited unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@itn.co.uk Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Hi EGNOS delivers a correction Signal. It's possible to receive it in realtime from a satellite or download using FTP. (I think it's here: http://www.egnos-pro.esa.int/ems/index.html) If the gpx file has an information whether the coordinates are already corrected, the EGNOS error correction could be added after upload to openstreetmap. The GPX file needs timestamps otherwise no correction is possible. Bernhard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
Hi, bernhard wrote: > EGNOS delivers a correction Signal. > It's possible to receive it in realtime from a satellite or download > using FTP. True, but I don't think the correction signal is something like "add .0182 to longitude and subtract .0012 from latitude". It is rather "correct timing from satellite #12 by factor 0.1 and correct timing from satellite #04 by 1.2" or so; corrections that have to be applied well before the device spits out a lat/lon value. The website you quoted does say something about applying corrections at the "post processing" stage but unless someone more knowledgeable than myself says otherwise, I'll assume that in GPS receiver terms, "post processing" still means pre-lat-lon-output. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - ( tag:landuse=garages )
Hi All, The voting for landuse=garages is started. Unfortunanly I am not a native english speaker, so i cannot deside if 'garages' is the best word. Since comments are quite contradictory, i desided to vote this proposal as it is now. If your think 'garages' is not a best word, please suggest your variant. Zkir aka Kirill _ From: Kirill (Zkir) [mailto:mekil...@yandex.ru] Sent: Friday, October 02, 2009 1:45 AM To: 'talk@openstreetmap.org' Subject: [tagging] Feature Proposal - RFC - ( tag:landuse=garages ) Hi All, If there is no new comments for this proposal (in the discussion page) in the next two days, it's status will be set to 'voting'. _ From: Кирилл [mailto:mekil...@yandex.ru] Sent: Saturday, September 12, 2009 1:50 AM To: 'talk@openstreetmap.org' Subject: [tagging] Feature Proposal - RFC - ( tag:landuse=garages ) Hi All, The proposal for new feature landuse=garages is ready for discussion. http://wiki.openstreetmap.org/wiki/Proposed_features/tag:landuse%3Dgarages Comments are welcomed! //Zkir ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] EGNOS
El Lunes, 5 de Octubre de 2009, Frederik Ramm escribió: > but unless someone more knowledgeable than myself says otherwise, I'll > assume that in GPS receiver terms, "post processing" still means > pre-lat-lon-output. You're correct. I had been working with sub-metric GPS receivers, and what they do is (IIRC) record the phase carrier of the GPS sats (or some other pre-lat-lon info). Then you download the data to a computer, launch mmoffice, and let that software do the math: get the pre-lat-lon stuff, plus the correction stuff, and spit out pretty coordinates. It is better explained in http://en.wikipedia.org/wiki/Real_Time_Kinematic . Cheers, -- -- Iván Sánchez Ortega You display the wonderful traits of charm and courtesy. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] RR8 - Possible International Vandal (assistance required in various countries)
> Is there any simple way (i.e. not involving setting up your own Mapnik > server) to test Mapnik rendering locally, without polluting OSM, and > perhaps more importantly, without waiting an hour or more to see your > update. I'm working on a Virtual-Box image with a complete set up rendering stack to play with your own rendering rules and custom rendering styles. You'll be able to just do #> osm-load --api 8.1098,49.7439,8.2382,49.8316 #> osm-render --bbox 8.1098,49.7439,8.2382,49.8316 or for bigger areas #> osm-load --bzip2-file germany.osm.bz2 stay tuned! Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, 5 Oct 2009, Mike N. wrote: > I recently set out to do an all-inclusive map of a section of town. > Perhaps I'm unfortunate enough to live in a city of lawyers, but it seems > that a large entire section of town consists of law offices.I can't > believe I'm not the first person to want to tag a law office as a shop > category (I may have completely missed an existing tag). The process of > creating a new tag is laborious: > Search the wiki for approved tags that don't appear in presets > Search the wiki for a proposed tag to be able to at least choose a > more common tag > Search TagWatch - I didn't play with this for long, but the links from > the wiki to TagWatch don't make it easy to query a list of tags in use for > key shop for example. I used shop=solicitor because I had heaps of stuff to put on the map and no time to do any exhaustive search. Any tag I found on the wiki later I adjusted to a generally used one. I'm quite happy to change my tag to shop=lawyer. You have described an interesting example of the difficulties of wishing to be a conformist on OSM and I have described the example of how easy it is to be an anarchist. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC should decide
On 05/10/09 11:04, Dave Stubbs wrote: > As the person whose first came up with a no-names map for London > (well, actually it was a named map of London, turned into a nonames > map on SteveC's suggestion), I have an *official leadership > announcement* to make: > > There shall be no tagging of unnamed roads. It is not important. They > show up on the no-names map -- big deal -- its a mapping aid not a > holy grail of "there shall be no highlighted roads". Just deal with > it. So why did you make the noname map in the first place, if it's not important? Have you changed your mind about its usefulness? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
> You have described an interesting example of the difficulties of wishing > to be > a conformist on OSM and I have described the example of how easy it is to > be > an anarchist. The only reason for wanting to be a conformist is the possibility for more meaningful rendering sooner. Currently, shop=xyz on a node, where xyz is unknown, results in no name rendering on Mapnik. So, I've revised my approach to placing non-rendering shop types on the building outline where the name= tag will be shown. Previously, I had preferred the lone node inside a building outline so that new people can more easily spot buildings that have not been identified, then they can drop a POI icon without resulting in duplicate name rendering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New mailing list - tagg...@openstreetmap.org
Hi all, I'm pleased to announce a new mailing list: tagg...@openstreetmap.org . You can subscribe at: http://lists.openstreetmap.org/listinfo/tagging The mailing list description is "tag discussion, strategy and related tools". The list will enable those who want to discuss tags to do so at any length they like, especially those who might not subscribe to talk@ because of its general high volume but would like to be involved in tagging discussions. Equally, it will help those who are less interested, and only use a subset of tags in their mapping work, avoid the discussions. Enjoy. :) cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New mailing list - tagg...@openstreetmap.org
On Tue, Oct 6, 2009 at 12:02 AM, Richard Fairhurst wrote: > I'm pleased to announce a new mailing list: tagg...@openstreetmap.org . So, we still have to create a "what is thinking Frederik" list and a "what is not saying SteveC" and we can close the main osm-talk list. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Mike N. wrote: > So, I've revised my > approach to placing non-rendering shop types on the building outline where > the name= tag will be shown. > > > If I understand you correctly your mapping/tagging so the name is displayed along the outline of the shop. unknown boundaries also do this. I believe this is considered an error in Mapnik which is known about. I think(?) a fix is being work on. I'm sure a mapnik programmer could give more accurate info. Personally I don't like the way the name wraps around corners making it almost impossible to read. That's why I don't map for the render & try & wait patiently for them to catch up Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
>> So, I've revised my approach to placing non-rendering shop types on the >> building outline where the name= tag will be shown. >> > If I understand you correctly your mapping/tagging so the name is > displayed along the outline of the shop. I add a building=yes which renders the building footprint, and also eliminates the name wrapping around the corners. > Personally I don't like the way the name wraps around corners making it > almost impossible to read. I try to add something with 'substance' - landuse, etc to eliminate the name wraps. >That's why I don't map for the render & try & wait patiently for them to >catch up I find it difficult to be a monk who labors away at a mountain of XML that may see the light some day. I also like to show people what I am working on - it doesn't need to be fancy, but I also use it to double check my work. Just as reading your essay in reverse helps you catch errors, so does looking at recent work in one form of rendering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New mailing list - tagg...@openstreetmap.org
+1 Thanks Richard Fairhurst. Sam On 10/5/09, Pieren wrote: > On Tue, Oct 6, 2009 at 12:02 AM, Richard Fairhurst > wrote: >> I'm pleased to announce a new mailing list: tagg...@openstreetmap.org . > > So, we still have to create a "what is thinking Frederik" list and a > "what is not saying SteveC" and we can close the main osm-talk list. > > Pieren > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Mike N. wrote: >I find it difficult to be a monk who labors away at a mountain of XML > that may see the light some day. I also like to show people what I am > working on - it doesn't need to be fancy, but I also use it to double check > my work. Just as reading your essay in reverse helps you catch errors, so > does looking at recent work in one form of rendering. > > > I agree with you. It fustrating to have to do it trial by error never knowing > if the taggin is incorrect or the render doesn't accept the values yet. The > delay in rendering is irritating but understandable. A sandbox with a limit > of a view ways/areas to allow immediate render would be extremely useful. > Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
> The delay in rendering is irritating but understandable. A sandbox with a > limit of a view ways/areas to allow immediate render would be extremely > useful. I read somewhere today that someone is working on this - a web site where you'll be able to designate a bounding rectangle with near immediate rendering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, Oct 5, 2009 at 8:01 PM, Mike N. wrote: > > > The delay in rendering is irritating but understandable. A sandbox with a > > limit of a view ways/areas to allow immediate render would be extremely > > useful. > > I read somewhere today that someone is working on this - a web site where > you'll be able to designate a bounding rectangle with near immediate > rendering. > I don't see much of a rendering delay with Mapnik... the last few changesets I've uploaded have shown up on the Mapnik layer within 5 minutes. If it's not showing up for you, make sure you clear your cache (control+reload or shift+reload depending on browser should help, too). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
Ian Dees wrote: > > I don't see much of a rendering delay with Mapnik... the last few > changesets I've uploaded have shown up on the Mapnik layer within 5 > minutes. > I think it depends greatly on the time of day & maybe where you are in the world. Does anyone know if the servers are all in one place? Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging schema
On Mon, Oct 5, 2009 at 8:21 PM, Dave F. wrote: > Ian Dees wrote: > > > > I don't see much of a rendering delay with Mapnik... the last few > > changesets I've uploaded have shown up on the Mapnik layer within 5 > > minutes. > > > I think it depends greatly on the time of day & maybe where you are in > the world. > > Does anyone know if the servers are all in one place? > > The servers [0] are all in the same spot. [0] http://wiki.openstreetmap.org/wiki/Servers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SteveC should decide
2009/10/6 Gervase Markham : > On 05/10/09 11:04, Dave Stubbs wrote: >> As the person whose first came up with a no-names map for London >> (well, actually it was a named map of London, turned into a nonames >> map on SteveC's suggestion), I have an *official leadership >> announcement* to make: >> >> There shall be no tagging of unnamed roads. It is not important. They >> show up on the no-names map -- big deal -- its a mapping aid not a >> holy grail of "there shall be no highlighted roads". Just deal with >> it. > > So why did you make the noname map in the first place, if it's not > important? Have you changed your mind about its usefulness? It sounds like he made it to see which roads needed surveying to acquire their name, however I'm still confused why people use noname=yes when the street does have a name but not a street sign, as I posted before there is actually a few streets near here on the golf course which really aren't named, the buildings a just unit numbers. Anything without a street sign should be reported to someone in local government, they may not be aware that their sign has been damaged/destroyed, and to ask them for the name, there is 2 streets with vandalised signs I keep meaning to annoy council about here. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
