Re: [OSM-talk] [RFC] highway=unclassified currently is too ambiguous, so here's my proposal to fix it.
I haven't been participating for awhile, but wasn't some committee going to come up with a solution? Ideally there would be separate tagging systems for all the different classes of information, e.g. surface type, width, number of lanes; route numbers and codes, government classification, popularity, etc.; and then the renderer would figure out how to display the information. However, in a given area there may only be five or six kinds of roads and it obviously easier to collect some kind of general description, e.g. four lane state highway, then to type in all those details. Unfortunately people in different areas simply apply whatever label will give them the rendering they want instead of fixing the rendering. On Sat, Aug 8, 2009 at 2:45 AM, Martin Koppenhoefer wrote: > 2009/8/7 Roy Wallace : > > On Fri, Aug 7, 2009 at 1:37 AM, Richard > > Mann wrote: > >> As indicated, I've had a go at a rewrite of the unclassified page: > >> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified > > > I've added my thoughts to the discussion page. Replicated below: > > > > Presently IMHO it's an absolute mess. Try reading the whole page > > through once, then see if you can explain to someone what it means. Or > > better yet, get a non-OSM'er to read it and see if they understand. > > Here's another idea: there appears to be several distinct definitions > > of the tag in current use, according to talk and talk-au mailing list > > discussion e.g. > > > > 1. urban roads in industrial areas less important than highway=tertiary > > 2. "something bigger than highway=residential but smaller than > > highway=tertiary" > > 3. rural roads less important than highway=tertiary > > 4. "a road equal to a residential road, but outside residential > > areas"; "a road roughly equal to residential but without people living > > there" > > 5. "the lowest street/road in the interconnecting grid, be it in > > urban or rural areas" > > > > Rather than trying to unify the different usages into one big > > confusing mess, maybe it would be better to separately explain each > > current usage? i.e. "This tag is used if the road is A or B or C or D > > or E". This more closely reflects reality and IMHO will not be any > > harder to read than the current mess. This could also lead the way to > > *eventually* replace each different usage with a tag of its own. > > I completely agree with Roy. Be it for the mess created as for the > summary of current use. Let's use this. > > cheers, > Martin > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Jeffrey John Martin dogs...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Korea users
I've noticed a lot of new data on Korea. Who is working on Korea and is there a separate email list? -- Jeffrey John Martin dogs...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Foundation acknowledged as non-profit?
I think most international organizations create a branch in each country and then you can just donate to your local branch. The branch in each country can then pay dues to the international organization or in some cases the international body can provide funding for projects in the local countries. On 2/6/09, Peter Miller wrote: > > On 5 Feb 2009, at 19:54, Jens Müller wrote: > >> Is the OSMF acknowledged as a charity, non-profit organisation, or >> whatever is necessary under UK law to make donations tax deductible? >> >> I'm asking because of C-318/07, which makes this relevant for other >> Europeans, as well .. > > It is not currently a charity. I understand that it is currently a > not-for-profit company. > > Possibly a foundation director would like to give their position on > conversion to charitable status? > > > > > Regards, > > > Peter > > >> >> >> >> ___ >> legal-talk mailing list >> legal-t...@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/legal-talk > > > ___ > legal-talk mailing list > legal-t...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/legal-talk > -- Jeffrey John Martin dogs...@gmail.com ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Rights management lecture
I found this lecture about rights management. It's not about DRM software, but about how organizations manage rights. http://videolectures.net/edrene08_duncan_rme/ -- Jeffrey John Martin [EMAIL PROTECTED] ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] firefox upload utility
I just saw this upload utility for Firefox. It looks like something cool to add to the website. http://www.fireuploader.com/#fupHome ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] vandolism on OSM
On Sat, Oct 4, 2008 at 6:34 AM, Dave Stubbs <[EMAIL PROTECTED]>wrote: > > > > I think my idea deals with non-obvious vandalism very well. > > A user of the data can choose to use data that has only certain > > tags by certain groups or individuals and therefore have an idea of how > > accurate that data might be. > > > > > Yes, but in a world of 65000 users you're left with a lot less data. > It may be enough for your purpose in which case that's great. For > smaller areas it probably works quite well, but I'm fairly sure it'll > hit a scalability problem. With OSM as a whole we rely on there being > more good guys than bad guys, and that's generally worked so far, but > you do have that instability problem in that it can take a while for > errors to be detected and corrected. > > The subtle vandalism is hard to spot because it looks genuine. You > only determine it isn't genuine with local knowledge or on the ground > observations. That means you can't trust anything until it's been > checked out by a trusted member and the more people you bring in as > members to hit your coverage goals, the more chance you get > compromised and start letting in lower quality data. > > How much of this is actually a problem depends a lot on what you are > actually trying to achieve. > > Dave > I think my idea would scale quite well. The key is that it's very flexible. If you and a few friends are interested in post box locations then you can tag areas as having correct post box data. I come along and add another post box. Until someone in the London Post Box Fanatics group tags it as accurate then the box I added would not have the tag and I could choose to only look at post box data approved by the group or not. We could then form another group; World Postal United. World Postal United would select the best groups based on reputation and give data tagged by those groups the World Postal United tag. Now if the London Postal Experts group started to get a better reputation then the Postal United might start giving approval to London Postal Experts instead of London Post Box Fanatics. Would I download all the data and sort on my PC or would I selectively download data? I'm not sure what would be best. Here in Korea I might tag areas as having accurate or semi-accurate street data. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] vandolism on OSM
On Fri, Oct 3, 2008 at 8:49 PM, Dave Stubbs <[EMAIL PROTECTED]>wrote: > On Fri, Oct 3, 2008 at 12:25 PM, Barnett, Phillip > <[EMAIL PROTECTED]> wrote: > > vegard wrote: > >> But we'll need a more permanent measure against vandalism. > >> Something that'll make it easy to reverse things. > > > > But note that our most potent weapon against vandalism is the ease and > > speed with which it can be undone. > > > > > > > > Frederick, > > That's only the case for OBVIOUS vandalism or accident, as in the OP, > that can be seen in a casual 'fly-over' the map. What about subtle vandalism > (renaming random streets, changing one-way directions etc) > > Even in areas that I have personally mapped, I doubt that I'd be able to > tell at a glance that this had happened without digging out my original > notes and comparing street by street(in effect, remapping the area) which I > wouldn't do without a huge visual clue. > > > > Well, none of the schemes proposed so far actually deal with the case > of subtle vandalism. They're all assuming it's possible to determine > whether an edit is good or not. The only fool proof way of doing that > is to send someone to check it out in reality, which is going to be a > fairly intractable problem. The obvious vandalism is the low hanging > fruit, and the obvious place to start if you're aiming for a more > stable map. I'd imagine people will do this for smaller areas in a > similar fashion to how we handle the coastlines for the cyclemap (ie: > we grab the data every so often, and just keep the old data if the new > looks too broken in a critical place -- at that point I usually try > and fix it of course). > > Dave > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > I think my idea deals with non-obvious vandalism very well. A user of the data can choose to use data that has only certain tags by certain groups or individuals and therefore have an idea of how accurate that data might be. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] vandolism on OSM
On Fri, Oct 3, 2008 at 7:24 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > > vegard wrote: > > But we'll need a more permanent measure against vandalism. > > Something that'll make it easy to reverse things. > > We have some good changes in store with API 0.6. > > > An idea I've had, is to add "revised"-tags to OSM data. > > Which is what Wikipedia is currently experimenting with. > > But note that our most potent weapon against vandalism is the ease and > speed with which it can be undone. > > > unless we put up a way to avoid random vandalism to > > pollute "the production" set of data, noone is gonna dare use our data > > Every day someone says "noone is going to use our data unless...". I > don't really take that seriously because reality proves them wrong. > > If anyone wants to have a strictly quality controlled OSM they can > easily do that and sell it as a paid service. But I believe it is going > to be much more expensive than just buying a set of TeleAtlas data, and > will have all the disadvantages of commercial geodata (errors take long > to get fixed, data is a year old, etc.) > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > Here is my proposal for Wikipedia. I hope they someday adopt it. Have a variety of tags concerning quality and let people filter with those tags. Anyone can form a group and each group would have its own tags that only that group can change. In this specific case some people can form a no vandalism group and tag data that looks to be vandalism free. People looking at the data could then filter based on the reputation of the groups. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Beijing weekend
There has been some discussion on this list before about the law against collecting geographic data in China. 2008/9/23 Hiroshi Miura <[EMAIL PROTECTED]>: > Hi, > > I have a chance to go to Beining this weekend. > There will be mapping chance this Saturday morning. > > One idea is that I have a chance to map the new transportation in Beijing, > which is opened just before Olympic! > eg. Airport to city. > http://www.urbanrail.net/as/beij/beijing-map.htm > > Could you suggest me where I should map or your POI? > # It's not possible to clime onto the great wall ! :-) > > A hotel staying will be here; > http://www.openstreetmap.org/?lat=39.97589&lon=116.33864&zoom=17&layers=B000FTF > > -- > HIroshi Miura > NTT DATA Corp. and IPA OSS center > （株）NTTデータ /（独）情報処理推進機構 > 三浦広志 > > ___ > 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] High-Precision GPS Survey Equipment?
On Tue, Aug 26, 2008 at 6:33 PM, Tim Waters (chippy) <[EMAIL PROTECTED]> wrote: > On 8/25/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Hi all, >> Just to give a hint at what is possible, the company I work for flagship >> receiver (L1/L2 dual frequency) can achieve sub-cm accuracy for static >> observations when tied into a nearby reference station (or other >> receiver). > > Anyone know if the very high accuracy receivers can maintain their > accuracy whilst on the move, in a car for example, or whether you'd > need to be static or do "frog-jumps" from point to point? > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > Here's how John Deere does it. I don't think it will do any good for interference from buildings though. http://en.wikipedia.org/wiki/StarFire_(navigation_system) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Map Maker
I'm using gmail. The way I read my user agreement google pretty much has the right to do anything they want with any information I give them. For that reason I'm careful not to put anything really important in my emails. I'm guessing that google would have the rights to the aggregate mapping data while any individual would only have the rights to their own contribution, unless they access it through google. On Wed, Jun 25, 2008 at 1:54 AM, X <[EMAIL PROTECTED]> wrote: > http://www.google.com/mapmaker/mapfiles/s/support.html > > Ready ... Fight ! > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Don't you just hate it when part 2...
Don't have that problem in South Korea. There are lots of English teaching jobs here if any mappers map the unmapped. -Jeff On Mon, Jun 9, 2008 at 9:02 AM, Shaun McDonald <[EMAIL PROTECTED]> wrote: > > On 8 Jun 2008, at 23:35, Nick Whitelegg wrote: > >> On Sunday 08 Jun 2008 22:35, you wrote: >>> yes! I do hate it,. but not because I don't regret walking or being >>> outside, >> >> Same with me too, though I might have gone somewhere else if I'd >> known! Guess >> the lesson is to make sure you know what the others in your area are >> doing... >> >> I think I may have met the guy out mapping today actually. About >> 17.30 I >> passed someone with a yellow Etrex but thought nothing of it, but it >> was in >> the common area. Good side of the coincident mapping isthat it looks >> like >> that area is pretty well covered now... >> > > The way I look at it, is that you will often find that if two people > survey an area, they will both think different things are more > important, or one will miss something. You can also use it as a way to > check what is already there, as there may be something missing or wrong. > > It has happened to me before many times, but as I've been able to add > to the data, and verify that what I have is the same as what is there > (or discover that there is a discrepancy and either change or resurvey > depending on my certainty). > > Shaun > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] layers or multiple databases or datasets
There was some post about tree information and another one about business hours. Maybe there should be more than one dataset? One just for streets and the things you would find on a typical navigation unit, and others with other stuff? Just a random thought. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Mapping distant objects by triangulation.
I couldn't find the other thread on this topic. How do you map an object, like a tower on top of a mountain, that you don't have access to without expensive survey equipment? My thought is to use a plumb bob to line up the unknown object with some known objects. I would find something like a phone pole between me and the mountain tower. I would move along a road until the pole and the tower line up. Now I have a straight line. Do it again with another strait line and I have two lines to define the location. Would that work? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide "completeness" tools
I'm very far from this in Korea, but I would guess in time some parts of the UK will need to be rechecked at some point. How can we make a system for rechecking an area? Maybe the completeness should be retired after a period of time. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
On Sun, May 11, 2008 at 7:21 PM, Steve Hill <[EMAIL PROTECTED]> wrote: > > When adding roads, you don't always know what classification of road it > is (e.g. primary, secondary, tertiary, unclassified, etc). Quite a lot > of people seem to add these sorts of roads as highway=unclassified, with > the idea that these can be fixed in the future when the status of the > road is discovered, but this is wrong since "unclassified" is a real > road classification. > > Is there a recommended way of tagging these roads? Leaving them > untagged has a couple of problems: there is no way to later determine > that the way is a road if it is left completely untagged, and the road > doesn't get rendered. > > It seems silly to take the attitude that this data shouldn't be rendered > until it is complete - the submitter probably knows lots of useful data > about the way, such as that it is a road which is accessible to cars, > the actual classification of the road isn't really as important as > knowing it is there and that you can drive down it. > > Having a highway=unknown_road or similar would also help with people > tracing yahoo images - render them in a lighter colour so it is obvious > that the road hasn't been fully mapped. There are probably 2 groups of > users who want different things from OSM in this regard: Mappers want > to be able to easilly see which bits of the map are complete, so having > roads which haven't had a proper survey tagged as such is helpful. Map > users want as complete a map as possible - knowing that there hasn't > been a proper survey is useful, but seeing a road with questionable > accuracy is often more useful than no road at all. > > -- > > - Steve >xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ > > Servatis a periculum, servatis a maleficum - Whisper, Evanescence > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > Did we ever decide what to do when a road continues but we didn't continue down the road? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] street traits
Here is my list of traits. Lane width. Number of lanes in each direction. Number of bidirectional lanes not controlled by signals. Number of bidirectional lanes controlled by signals. size of shoulder Center turn lane. In lane parking. Separate parallel parking. side of street Separate diagonal parking. side of street parking on shoulder parking partially on shoulder parking partially on sidewalk access: ramps only, ramps and full intersections, intersections, t intersections (divided highway). divided by barrier divided by median divided by park median width pavement On Sat, May 10, 2008 at 3:30 AM, Jeffrey Martin <[EMAIL PROTECTED]> wrote: > I was thinking about classifying roads in Korea. What criteria am I using > when I put a road in a classification? > > I'm starting to think that my support of the current use of the highway tag > was misguided. Maybe we should > be more specific. > > I know some people say they don't want to be stringing tape measures across > the road, but for most > countries I think there are only a handful of standard sizes for lanes and > shoulders. Once you know the > sizes for your country you can pretty much just eyeball it. > > A name for each kind of road in a person's country could be set up as an > editor feature. I select > "mountain road 2" from my list and it fills in the number of lanes, lane > size, shoulder size, etc. > for me. > > Another option might be to have some kind of bot that fills in specific > data based on country > specific highway tags. > > I think the first option is probably better. Would it be too complex to > base rendering on a combination > of specific road traits? > > -- > http://bowlad.com -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] street traits
I was thinking about classifying roads in Korea. What criteria am I using when I put a road in a classification? I'm starting to think that my support of the current use of the highway tag was misguided. Maybe we should be more specific. I know some people say they don't want to be stringing tape measures across the road, but for most countries I think there are only a handful of standard sizes for lanes and shoulders. Once you know the sizes for your country you can pretty much just eyeball it. A name for each kind of road in a person's country could be set up as an editor feature. I select "mountain road 2" from my list and it fills in the number of lanes, lane size, shoulder size, etc. for me. Another option might be to have some kind of bot that fills in specific data based on country specific highway tags. I think the first option is probably better. Would it be too complex to base rendering on a combination of specific road traits? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
Typos in real words are easier to detect than a mistake in entering a number. On Sat, May 10, 2008 at 2:45 AM, elvin ibbotson <[EMAIL PROTECTED]> wrote: > On 9 May 2008, at 12:21, Dave Stubbs wrote: > > > The mapping to numbers doesn't gain us anything. It doesn't let us do > anything we can't already do, or make it any easier as far as I can > see. > > > If the database, which is accessed by programmers, was numerically based, > it would be be more amenable to algorithmic logic. At the simplest level, > selecting elements with values above/below certain levels. The numbers would > of course have to follow some logical pattern. Similar procedures using the > current tags involve clumsier code like 'motorway OR trunk OR primary' and, > if users are actually typing these words in (rather than selecting from > human-friendly menus presented by the editor) a typo such as 'secodnary' > cold corrupt the database and prevent the feature being seen by map viewers > or routing engines for example. > > > I think you were actually suggesting something like "type=11" -- where > 10-20 means roads, 30-40 could mean railways etc. But as far as this > argument goes it doesn't really make much difference, other than > leaving us with a massive allocation problem which has been neatly > sidestepped by using free-form tagging. > > > Yes free-form tagging avoids having to decide on a pattern and allows for > open-ended evolution, but it doesn't work if it's completely free-form. I > could describe many roads around here as 'highway=country lane" but would > they get rendered? The fact that there are tagging recommendations > acknowledges that anarchy would not work. But a data structure would have to > allow change and evolution (at the simplest level, leaving spare numbers for > future use) and this is a challenge. > > > Indeed point missed again. > We DON'T DO (sorry Richard) highway=red. We do highway=primary and you > can make that any colour you like... same as you can do with > highway=13/type=13 -- it makes no difference is my point. Numbering > the highways won't help. > > > Now I'm confused. I'm not suggesting numbers to avoid red highways for > goodness' sake! > > > It could yes. There are a couple of issues with this mostly to do with > actually maintaining the style sheets and providing the processing > power/disk space. > > > Moore's Law should take care of those :-) > > > > No problemo! Special viewers like the cycle map would simply apply their > own > filters. And with well-structured data a map viewer could even have > settings > (eg. cycle routes on/off) allowing it to be customised by the user, making > a > proliferation of specialist viewers unnecessary. > > > Hmm.. yes, maybe. But the point of your e-mail was essentially > numbering everything, and that really doesn't help us with this goal. > > > It's just that numbers are easier for programmers (see above). Users would > never see them. They would see words in their own language and the > viewer/editor would map words to numbers. > > elvin > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
Maybe what we need are some guidelines for making tags. "You can make any tag you want, but here are some general principals about what makes a good key and what makes good values for those keys." At the very least we would have a framework for discussion. Someone type something up on the wiki. On Sat, May 10, 2008 at 12:48 AM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > > > > I can see the attraction to the use of numbers for the values of the > > highway tag. Having a new system that does not use terms that > > have other meanings can force people to think about the OSM > > definitions of the values. The UK centric terms have this effect > > for me. I have to think about what motorway means for the US > > or Korea in terms of the OSM definition because I have no competing > > definition of the term motorway in my mind. For me motorway > > only has an OSM definition. > > > > People in countries with roads called motorways have a conflict > > in their minds. If a section of a UK motorway is a single lane > > dirt track then someone in the UK may be tempted to label > > it as a motorway because it has a motorway sign. (That's just > > a hyperbole to make a point. Let's keep discussions of the > > highway tag itself on a separate thread.) > > > > One solution to this psychology problem is to use terms > > that do not have a local meaning. Numbering might be > > one way to do that for some tags but not for others. > > > > Another way to solve this psychological problem is to hide > > the recorded data from the user. Something like presets > > was suggested. Having different terms being used by the > > person who writes the rendering rules and the person > > collecting the data might cause other problems. > > > > > There are some genuine problems that need solving -- tag translation, > tagging hierarchies, tag documentation and guides, and some "bad" tags > in common use to name but a few. > > Unfortunately people seem most interested in solving these problems > via the magic bullet approach. This basically involves turning > everything on it's head, adding a level of indirection or two, putting > in some extra technical elements, and finally hoping that someone will > take the opportunity of the wholesale change to actually fix the > problem. > > The highway tag has well known problems; mostly that it's a highly > subjective short cut for lots of tags and widely differing concepts, > of which nobody is entirely sure which takes precedence. This doesn't > get fixed by making everyone use numbers. Numbers are not an > intrinsicly better model of road types, nor do they make it easier to > create such a model. > > Tags can be translated from English just as easily as they can be > translated from numbers. Presets can be created using english tags as > well as they can for numeric tags. > > Numbers do not possess a natural hierarchy of feature types, nor do > they make such hierarchies easier to create. > > Numbers are an abstraction, that's all they are. The present tag > names/values are also generally abstractions... just human readable > ones. > > Dave > > PS. This isn't aimed at anyone in particular, just a general observation. > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
The rendering should be separate from the data. Marking a hiking trail as an autobahn so it will be a different color or be visible on higher zoom levels I think we all agree is wrong. Provided the data is correct, I don't see a problem with altering the way data is collected and recorded to make it easier for renderers, and those who program them and write the rendering rules. I can see the attraction to the use of numbers for the values of the highway tag. Having a new system that does not use terms that have other meanings can force people to think about the OSM definitions of the values. The UK centric terms have this effect for me. I have to think about what motorway means for the US or Korea in terms of the OSM definition because I have no competing definition of the term motorway in my mind. For me motorway only has an OSM definition. People in countries with roads called motorways have a conflict in their minds. If a section of a UK motorway is a single lane dirt track then someone in the UK may be tempted to label it as a motorway because it has a motorway sign. (That's just a hyperbole to make a point. Let's keep discussions of the highway tag itself on a separate thread.) One solution to this psychology problem is to use terms that do not have a local meaning. Numbering might be one way to do that for some tags but not for others. Another way to solve this psychological problem is to hide the recorded data from the user. Something like presets was suggested. Having different terms being used by the person who writes the rendering rules and the person collecting the data might cause other problems. On Fri, May 9, 2008 at 6:27 PM, elvin ibbotson <[EMAIL PROTECTED]> wrote: > Much debate centres around the way features are tagged and how they > are rendered (for example recent discussion of golf course tagging, > the term 'highway', rendering power lines,...) and it seems that much > of this is inextricably involved with the OSM data itself. I > wondered if it was time, while OSM is still relatively young and > before it becomes too ossified and institutionalised, for the > approach to be reviewed. > > My own thoughts, for what they are worth, are that the data structure > should be language/locale agnostic. For example, ways could have a > numeric type field with, hypothetically, 10-19 being used for roads. > In this scenario 11 might be a UK motorway, an Italian autostrada or > an American interstate, while 19 might be a rough track (10 being > reserved for some not-yet-invented super highway, after all some of > us were here before motorways). > > The editors used to input data (Potlatch, JOSM, whatever) would hide > this structured data from the user and translate it to/from human > language. One immediate advantage is that a German user could tag an > autobahn rather than a motorway and global users would not have to > use language clearly derived from the British motorway/trunk road/A/B > (and little-known C) road classification system. Instead, local > nomenclature would be mapped (no pun intended) to the underlying data > structure by the local edition of the editor. Highways are an obvious > example we are all familiar with, but the principle would apply to > all feature types. Places of worship could be mapped as cathedrals, > churches, chapels, etc in Britain or as mosques, temples, shrines, > whatever in the east. > > Rendering of the data is I think less tied up with the data itself, > but again could be implemented differently by different map viewers. > My paper road map of Ireland shows primary roads red in Ulster and > green in Eire. Autbahns are green on my map of the Alps while > autopistas are patriotically red and yellow on my Spanish map. Local > or customisable viewers are possible with the current OSM but not, as > far as I know, implemented yet, but the principle of separating the > core data from the way it is described and depicted is, I believe, > important. > > Another aspect of the base data structure is that of level-of-detail > (LoD) filtering. This is obviously done at present (villages and > footpaths disappear as you zoom out) but is dictated by the people > who code the viewers and is not, as far as I know, very well > addressed in the API, so LoD filtering has to be done after data has > been acquired, when it should be possible to specify LoD when > requesting data. If LoD were considered in structuring the database > it would be easy to filter data (eg. road types 10-13 only or for > major ways of all types *0-*3). This is simpler for programming than > clumsily using named tags (highway=motorway|trunk|primary) and would > be invisible to users who might see autopista, autovia or carretera > general. > > elvin ibbotson > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com __
Re: [OSM-talk] TIGER mapping party
Why are there so many problems with the TIGER data? Where do the extra roads come from? Are they planned roads? Will they be releasing new data? What happens then? On Fri, May 9, 2008 at 6:13 AM, Richard Fairhurst <[EMAIL PROTECTED]> wrote: > SteveC wrote: > > > I and others have been doing a lot of fixing of TIGER data all over > > the US. > > Here's a very good example with before and after shots: > http://www.openstreetmap.org/user/Bridger/diary/1550 > > cheers > Richard > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] incline tag
I was looking at the incline tag and noticed the proposal for an incline to be applied to ways. The discussion on the wiki page seemed to support it and it was rejected. Is there a missing part of the discussion? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] WTF ! (about gps traces)
I have few track where on part is good and another part is bad. I should probably edit those tracks and cut out the bad part, but I haven't found an easy way to do that. On Sun, May 4, 2008 at 12:58 AM, Sven Grüner <[EMAIL PROTECTED]> wrote: > Karl Newman schrieb: > > Or maybe the tracks need a moderation/voting system. If the tracks are > voted > > down below a certain threshold, they won't be downloaded? Would need > some > > careful thought to prevent malicious voting down of good tracks, though. > > Even if the editors had a way to hide certain tracks, that would be > helpful. > > I've seen a few low-quality tracks in my area that I would like to make > go > > away. > > The user could (optionally) specify this threshold when requesting data. > This way one could avoid bad tracks when enough good ones available and > fall back on the bad ones when there's no alternative. > > Alternatively a request would still return all Tracks but each track is > returned along with it's quality level so that the editors can blank out > certain levels on demand. > > I believe that somewhere in the distant future when data maintenance > becomes more important than data creation the track handling will > improve dramatically. > > regards, Sven > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] WTF ! (about gps traces)
When I download in JOSM I would like each track to be a separate layer. I find it helpful when working with my own tracks to make them different colors or turn individual tracks on and off. On Sun, May 4, 2008 at 1:08 AM, Shaun McDonald <[EMAIL PROTECTED]> wrote: > > On 3 May 2008, at 16:58, Sven Grüner wrote: > > > Karl Newman schrieb: > >> Or maybe the tracks need a moderation/voting system. If the tracks > >> are voted > >> down below a certain threshold, they won't be downloaded? Would > >> need some > >> careful thought to prevent malicious voting down of good tracks, > >> though. > >> Even if the editors had a way to hide certain tracks, that would be > >> helpful. > >> I've seen a few low-quality tracks in my area that I would like to > >> make go > >> away. > > > > The user could (optionally) specify this threshold when requesting > > data. > > This way one could avoid bad tracks when enough good ones available > > and > > fall back on the bad ones when there's no alternative. > > > > Alternatively a request would still return all Tracks but each track > > is > > returned along with it's quality level so that the editors can blank > > out > > certain levels on demand. > > > > I believe that somewhere in the distant future when data maintenance > > becomes more important than data creation the track handling will > > improve dramatically. > > > > Talking of optional downloads, I'd like an option to not download > any trace made before date x, within bounding box y due to the fact > that there is a change in the road layout in the area. > > Shaun > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] clipboard on handlebars
When I got home some of my notes for my waypoints didn't make sense. I realized I was trying to take note only every third or forth waypoint and misremembering them. Sometimes the simple solution is the answer. I grapped some big clips from the office and a folder with a lever action clip. I bent back the cover, trimmed it down to a triangle shape, cut a notch for the speedometer cable etc. My data is much better. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Meaning of
Some things I have read on the internet say that in some jurisdictions it may not be possible to place things in the public domain. There are two big problems I've read about. (You might want to move this to OSM-legal.) First is that someone can include public domain material in their own work and not tell the reader. The reader then does not know that they can copy or make derivative works from those public domain portions without permission. Second, derivative works are now under a new copyright and no longer free (libre). On Wed, Apr 30, 2008 at 7:48 PM, Jukka Rahkonen <[EMAIL PROTECTED]> wrote: > Hi, > > I concluded that I'd rather see my contributions in public domain and > added > the PD-user template to show that. I wonder what does it mean in > practice. > Is it now possible for me or anybody else to extract all features I have > created and which have never been touched by other users? How about ways > created originally by me but edited later by others? How should I work > in the future to guarantee that my edits will be free? Should I do all > new work in some other environment and store it there before donating > it to OSM or what? I am now only speaking about creating totally new > features, not editing anything done by others. > > -Jukka Rahkonen- > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Vandalism, was Vandalism in Trumpington
Does the project have any long term plans on how to deal with vandalism? Should some features be locked? Do we need some kind of hierarchy with block captains and country coordinators? (I don't want that.) On Sun, Apr 27, 2008 at 7:36 AM, David Earl <[EMAIL PROTECTED]> wrote: > Would it be possible to roll back changes made by user Katie after 17:40 > on April 16? This user has removed or overlaid quite a few roads around > Trumpington, Cambridge, and replaced several streets with cycleways, run > a tertiary road along the river and across a farm track, and generally > made a complete mess of my careful mapping in that area. > > I could undo it manually, but the changes are significant and it would > be easier if this could be done automatically. > > I will send her (presumably) a message. > > David > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] GPS recommendations
"I think that either of these units will serve you well and, in my opinion, any purchasing decision should be made on the basis of features, not the brand of chipset." I think he could also add that chip manufacturers don't have a lot of control over things like antenna placement, and case design when someone puts one of their chips in a device. I bet that could make a lot of difference. On Fri, Apr 25, 2008 at 8:23 AM, Karl Newman <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 3:40 PM, Andy Robinson (blackadder) < > [EMAIL PROTECTED]> wrote: > >> Jeffrey Martin wrote: >> >Sent: 24 April 2008 10:50 PM >> >To: David Earl >> >Cc: talk@openstreetmap.org >> >Subject: Re: [OSM-talk] GPS recommendations >> > >> > >> >I bought a Garmin HCx Vista. Does the "high sensitivity" mean >> >that it's better than other receivers or that they are just now >> >catching up to other receivers? >> >> It should mean that its better than the sirf star II chipsets which you >> find >> in many older devices but its not as far as I am aware the sirf star III >> chipset that everyone raves about. I've not seen any comparison between >> the >> sirf star III and the chipset used by Garmin in their "H" devices. >> >> Cheers >> >> Andy >> > > The Garmin eTrex H series use a MediaTek chipset. I've seen a few > comparisons with the Sirf Star III, such as this one: > http://gpstracklog.typepad.com/gps_tracklog/2007/08/mediatek-gps-ch.html > > Generally the conclusions from the reviews I've read are that the MediaTek > performs equal to if not better in some cases than the Sirf Star III > chipset. > > Karl > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] GPS recommendations
It works for me also. I usually get 8m in Korea. I just have no idea if that is good or not. I don't think WAAS makes a difference here. I see no difference if it's turned on or off. On Fri, Apr 25, 2008 at 7:47 AM, Dermot McNally <[EMAIL PROTECTED]> wrote: > On 24/04/2008, Jeffrey Martin <[EMAIL PROTECTED]> wrote: > > > I bought a Garmin HCx Vista. Does the "high sensitivity" mean > > that it's better than other receivers or that they are just now > > catching up to other receivers? > > I have exactly this device and I love it. Its sensitivity is very > high, to the extent that it routinely gets a fix from indoors. Heavily > wooded areas or tall buildings don't bother it. I'm also very happy > with the accuracy and consistency of the trails it makes. > > Dermot > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] GPS recommendations
On Fri, Apr 25, 2008 at 4:48 AM, David Earl <[EMAIL PROTECTED]> wrote: > On 24/04/2008 19:57, Laurence Penney wrote: > > I quite liked my Nokia N70 + BlueGPS (Sirf3, non-logging) + > > nmea_info.py combo. So much so that I bought another BlueGPS when I > > left my first one on a train in a good position near the window. I > > can't find its replacement now, so wonder if I left that in a taxi, > > bleary-eyed after some flight. Having an all-in-one is quite a bit > > less hassle so I'm sticking with my N95 + SportsTracker for now - will > > be good for a day out when I buy a spare battery. > > I've been very happy with my Nokia N810 internet tablet. The built-in > GPS seems pretty good - I thought it had lost it going through some > light woodland the other day, as I was on a bit of already mapped road, > but in fact mine was right and the existing was wrong. Of course it does > lose signal sometimes. When I bought it I did some side-by-side session > with my Garmin Geko 301 and I think the Nokia was more accurate and lost > the signal less often. > > I've adapted the in-car holder to be a handlebar mount on my bike, and > made some minimal changes to its Maemo Mapper application so that I get > one-touch-anywhere-on-the-screen auto-numbered waypoints (which means I > can wear gloves in winter and still get waypoints). I can use a > bluetooth earphone/mic to take an audio commentary on the device, and > when I get home the WAV files and GPX files can just be copied over the > network on WiFi and synced in JOSM using the continuous audio features I > added. > > David > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > I bought a Garmin HCx Vista. Does the "high sensitivity" mean that it's better than other receivers or that they are just now catching up to other receivers? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bus Stops
That link is broken. Try: http://wiki.openstreetmap.org/index.php/Relations and http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5 On Thu, Apr 24, 2008 at 9:19 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 12:22 PM, Lester Caine <[EMAIL PROTECTED]> wrote: > > Jeffrey Martin wrote: > > > I've made a decision for what I am going > > > to do. > > > > > > If I wait until there is some standard way > > > it will be a hassle to find all these stops > > > later instead of putting them in now > > > with all the other data, and I might loose > > > my little scraps of paper. > > > > > > Here's my plan of action. I'm going to put > > > a node on the exact location of each > > > bus stop offset from the way. I don't want > > > to loose that location data until I'm sure we > > > want to throw it out. Putting a node on the > > > way instead would essentially erase the location > > > of the stops and shelters. > > > > > > If someone wants to come along later and put > > > a node on the way or make some kind of association > > > they can do that. > > > > That does seem to be the sensible way of doing it, in the absence of any > other > > guidelines. What of cause is missing is some means of relating it easily > to > > the way that then are actually linked to ? > > > > A nice 'is_in' link to the 'unique_id' of the way so that one can > actually > > find all the bus stops on a route ;) Looking at the way things have > developed, > > is there any reason we can't set a tag for is_in, and then select a way, > so > > that the key becomes is_in=# ? > > > > I don't think Relations has the necessary structure yet to be useful > here? > > If you want to link two nodes together, then the easiest most obvious > way of doing it is to use a way. A way is an object that links two or > more nodes afterall. > If you want to link a node and a way, the a relation is your tool. > This is exactly what relations do, they link and relate objects -- the > advantage over putting IDs in tags is that any editor that supports > relations in general will know about the connection as will the API, > and the DB can maintain referential integrity so you don't end up with > hanging links. > > You can do nice things with the API such as > http://api.openstreetmap.org/api/0.5/way//relations -- which > tells you what relations the way belongs to. > > Dave > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bus Stops
On Thu, Apr 24, 2008 at 9:19 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 12:22 PM, Lester Caine <[EMAIL PROTECTED]> wrote: > > Jeffrey Martin wrote: > > > I've made a decision for what I am going > > > to do. > > > > > > If I wait until there is some standard way > > > it will be a hassle to find all these stops > > > later instead of putting them in now > > > with all the other data, and I might loose > > > my little scraps of paper. > > > > > > Here's my plan of action. I'm going to put > > > a node on the exact location of each > > > bus stop offset from the way. I don't want > > > to loose that location data until I'm sure we > > > want to throw it out. Putting a node on the > > > way instead would essentially erase the location > > > of the stops and shelters. > > > > > > If someone wants to come along later and put > > > a node on the way or make some kind of association > > > they can do that. > > > > That does seem to be the sensible way of doing it, in the absence of any > other > > guidelines. What of cause is missing is some means of relating it easily > to > > the way that then are actually linked to ? > > > > A nice 'is_in' link to the 'unique_id' of the way so that one can > actually > > find all the bus stops on a route ;) Looking at the way things have > developed, > > is there any reason we can't set a tag for is_in, and then select a way, > so > > that the key becomes is_in=# ? > > > > I don't think Relations has the necessary structure yet to be useful > here? > > If you want to link two nodes together, then the easiest most obvious > way of doing it is to use a way. A way is an object that links two or > more nodes afterall. > If you want to link a node and a way, the a relation is your tool. > This is exactly what relations do, they link and relate objects -- the > advantage over putting IDs in tags is that any editor that supports > relations in general will know about the connection as will the API, > and the DB can maintain referential integrity so you don't end up with > hanging links. > > You can do nice things with the API such as > http://api.openstreetmap.org/api/0.5/way//relations -- which > tells you what relations the way belongs to. > > Dave > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > Short perpendicular ways leading to a bus shelter seems wrong to me. I'll read up on relations, but could you elaborate on how it might be used with bus shelters and stops? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bus Stops
I've made a decision for what I am going to do. If I wait until there is some standard way it will be a hassle to find all these stops later instead of putting them in now with all the other data, and I might loose my little scraps of paper. Here's my plan of action. I'm going to put a node on the exact location of each bus stop offset from the way. I don't want to loose that location data until I'm sure we want to throw it out. Putting a node on the way instead would essentially erase the location of the stops and shelters. If someone wants to come along later and put a node on the way or make some kind of association they can do that. On Thu, Apr 24, 2008 at 6:37 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 9:28 AM, Andy Robinson (blackadder) > <[EMAIL PROTECTED]> wrote: > > Jeffrey Martin wrote: > > >Sent: 24 April 2008 9:06 AM > > > > >To: Peter Miller > > >Cc: talk@openstreetmap.org > > > > >Subject: Re: [OSM-talk] Bus Stops > > > > > > > >Some people advocate nodes off to the side of the way > > >to represent the location of the pole or shelter in relation > > >to the road. > > > > > >Near where I live (Korea) there is often a shelter on > > >one side of the road for buses going both directions. > > >In that case I'm guessing I would put a shelter node > > >on one side of the road and a node that is not a shelter > > >on the other side. > > > > > >How do I relate these nodes to the way? I don't > > >like the idea of short segments perpendicular to > > >the way. > > > > Because a bus stop is a highway feature it really in my view should be > part > > of it. And because we map what we see on the ground then logically if > there > > are two bus stops not quite opposite each other then I place two nodes, > one > > for each and tag them appropriately. Placing short links from a bus > stop > > node placed off the highway to the highway itself is I guess fine if > those > > links are tagged as highway=footway, but personally I think that's a > lot of > > unnecessary effort and complexity in the map. > > Where as I think of bus stops as a pavement feature -- I really don't > care which road it's on, that's the bus driver's problem ;-) > I get the feeling we should be tagging both (if you can be bothered) > and linking the two -- but I'd prefer this didn't happen with short > footways... they come across to me as a bit fake. It's a virtual link, > so just keep it virtual: bus_stops=here or something. Alternatively > get out the relation box of tricks, but that might be unnecessarily > complicated. > It's certainly the better option than hacking someone's nice bus stops > into your own preferred style, even if you aren't going to do it that > way for new mapping. > > > > > The remaining issue revolves around the direction of the bus at a > particular > > node. I didn't have an answer to this until I looked at what the > signage was > > on my local bust stops. Now I find it easy to tag because each one > tells me > > in which direction the bus is travelling (eg "towards Birmingham"). So > I add > > a towards= tag and jobs a good un. > > This works! I generally find I need the help of a timetable to figure > out if I'm at the right stop as it's quite normal for the bus to be > heading in the wrong direction for the place stated if it's trying to > catch another stop on the way, but given the whole route information > you should be able to figure it out. > > > I'm not going to worry at the moment > > about how I might use this tag to make bus route information, the > important > > aspect is that the data that's needed to work that out later is in the > > database > > > And lets face it, the moment someone actually starts using this data > we'll probably decide to do something completely different anyway :-) > > Dave > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bus Stops
Some people advocate nodes off to the side of the way to represent the location of the pole or shelter in relation to the road. Near where I live (Korea) there is often a shelter on one side of the road for buses going both directions. In that case I'm guessing I would put a shelter node on one side of the road and a node that is not a shelter on the other side. How do I relate these nodes to the way? I don't like the idea of short segments perpendicular to the way. On Thu, Apr 24, 2008 at 1:45 AM, Peter Miller <[EMAIL PROTECTED]> wrote: > The EU standard Transmodel defines a Stop Point as 'A POINT where > passengers > can board or alight from vehicles'. For bus stops this means a single > pole, > shelter etc and for a place where there are three poles for different > services close together then there would be three entries. > > There are also places where buses stop where there is no physical > infrastructure but where buses stop which also need Stop Points. In rural > areas there might be a pole on one side of the road but buses stop in both > directions, or in some places there is not infrastructure on either side > of > the road. > > For there are a number of Stop Points close to each other then these can > be > grouped into Stop Areas that are 'A group of STOP POINTs close to each > other'. I suggest that we achieve this with a relationship call a 'Stop > Area' is people are keen to model it. > > For railway stations it can get more complicated as a platform can be made > up of sub platforms (long trains stop at platform 4 and two short ones can > stop at 4A and 4B etc). In this case I believe there should be a Stop > Point > for 4, 4A and 4B. > http://www.transmodel.org/en/transmodel/gloss/s.htm > > This interpretation is now being discussed as ISO level so is probably the > one to go with. > > Are we agreed that this is the appropriate interpretation for the feature > going forward. In which case shall I add this clarification and > interpretation to the relevant OSM tag page? > > Btw, Someone might like to ask the DfT in the UK at some point for a copy > of > the DB they have with the location of over 350,000 bus stops with their > names and the name of the associated street. I know the people but it > might > be better if it came from someone else, possibly from the foundation? > > > > Regards, > > > > > Peter > > > > Date: Wed, 23 Apr 2008 20:03:14 +0900 > > From: "Jeffrey Martin" <[EMAIL PROTECTED]> > > Subject: Re: [OSM-talk] Bus Stops > > To: "Mike Collinson" <[EMAIL PROTECTED]> > > Cc: talk@openstreetmap.org > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="iso-8859-1" > > > > How am I supposed to do bus stops? > > If two bus stops are on opposite sides of the road then I think maybe > they > > can share a node? > > > > I found in some email that you can make little short service links. I > > don't > > like that. The bus > > pulls over to the side of the road where I'm at. > > > > Sometimes they aren't exactly across the street from each other. > > > > Where I'm at there are lots of wood and concrete bus shelters. > > > > On Sun, Aug 12, 2007 at 12:07 AM, Mike Collinson <[EMAIL PROTECTED]> > wrote: > > > > > Excellent background information for basing our models. Thank you > > Peter. > > > > > > Mike > > > > > > > > > At 07:21 AM 11/08/2007, Peter Miller wrote: > > > > > > The conventional way of handling Bus Stops in the public transport > > > industry is to have a node for each individual point at which one can > > get on > > > a vehicle, so if there are two bus stops on opposite sides of the road > > then > > > they are represented as two nodes. If there are three bays in a row on > > one > > > side of the road then they are represented a 3 nodes in a row. Every > Bus > > > Stop in the UK has a unique code, and this is sometimes printed on the > > bus > > > stop itself. > > > > > > In the EU standards they are called 'Stop Points' (rather than Bus > > Stops) > > > so they can cover buses, tram, rail, ferry planes etc. > > > > > > In railway stations there is a Stop Point for each Platform (and each > > bay > > > in a bus station, each Gate for an Airport and each quay in a Ferry > > > terminal). > > > > > > Groups of local Stop Points (as they are called) are then arranged &g
Re: [OSM-talk] GPS recommendations
google email brings up ads related to your email This one came up for a waterproof pda: http://www.durateq.com/ On Thu, Apr 24, 2008 at 10:16 AM, Stephen Hope <[EMAIL PROTECTED]> wrote: > I think it's just as important to have a list of models NOT to buy. > Of course, this may get us into trouble with those manufacturers, but > as long as we stick to facts and not opinions, we should be fine. If > a particular model only records data points every 10 seconds (or not > at all), we need to know it's not suitable for this purpose. > > Unless I order online, any shop around here is going to carry maybe > 5-6 models, and probably on have 3-4 of those on hand, so my choice as > a shopper would be limited. If the recommended ones are not in the > few available, it would be nice to know if any lemons are. > > Stephen > > 2008/4/24 Gervase Markham <[EMAIL PROTECTED]>: > > http://wiki.openstreetmap.org/index.php/GPS > > says: > > "Thinking of getting a GPS Receiver to add data to OSM? These reviews > > are here to help." > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] bus stop tagging
In other posts I've talked about keeping data separate from rendering, but I recognize that you don't want the data so complex that it is too difficult to render. Here is an idea: for two shelters across the street from each other shelter=dual destination:left=Shinli destination:right=Daehwa a shelter on one side of the road, but the bus also stops across the street where there is no shelter shelter=left destination:left=Shinli destination:right=Daehwa On Thu, Apr 24, 2008 at 6:17 AM, Jeffrey Martin <[EMAIL PROTECTED]> wrote: > Where there are two bus stop shelters directly across the street from each > other > can they share a node? If I do that then I need a way to indicate the > direction > of each stop for the destination information. > > If I put a separate node for each one then I need to indicate the side of > the road. > > -- > http://bowlad.com -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] bus stop tagging
Where there are two bus stop shelters directly across the street from each other can they share a node? If I do that then I need a way to indicate the direction of each stop for the destination information. If I put a separate node for each one then I need to indicate the side of the road. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] GPS recommendations
I think OSM should stay away from direct recommendations. However, I could see OSM providing a forum for users to give their own personal recommendations. I think the problem with user reviews is that few users have access to many different products. If you are writing for a car magazine then you get to drive lots of different cars. The GPS I have now is pretty much the only one I've every used. I have no idea how it compares to other GPS units. On Thu, Apr 24, 2008 at 5:07 AM, Gervase Markham <[EMAIL PROTECTED]> wrote: > http://wiki.openstreetmap.org/index.php/GPS > says: > "Thinking of getting a GPS Receiver to add data to OSM? These reviews > are here to help." > > Well, if you have a particular model in mind, and want to know if it's > any good, then they are some help. But if your mother has told you "I > want a GPS with a screen for my motorbike, which I can also use for > gathering OSM data", then trying to read through and compare 50 > different models is impossible. > > Would it be really too controversial for OSM to have a "we particularly > recommend these N models" page, where N is small? Clearly, the NaviGPS > (which I own) would be one, because it's good and OSM gets some money. > But it would be great to have some sort of consensus on models in other > price/capability brackets, perhaps a little more than a few mailing list > messages saying "I have a Foo GPS, and it's fine". > > What do people think? > > Gerv > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bus Stops
How am I supposed to do bus stops? If two bus stops are on opposite sides of the road then I think maybe they can share a node? I found in some email that you can make little short service links. I don't like that. The bus pulls over to the side of the road where I'm at. Sometimes they aren't exactly across the street from each other. Where I'm at there are lots of wood and concrete bus shelters. On Sun, Aug 12, 2007 at 12:07 AM, Mike Collinson <[EMAIL PROTECTED]> wrote: > Excellent background information for basing our models. Thank you Peter. > > Mike > > > At 07:21 AM 11/08/2007, Peter Miller wrote: > > The conventional way of handling Bus Stops in the public transport > industry is to have a node for each individual point at which one can get on > a vehicle, so if there are two bus stops on opposite sides of the road then > they are represented as two nodes. If there are three bays in a row on one > side of the road then they are represented a 3 nodes in a row. Every Bus > Stop in the UK has a unique code, and this is sometimes printed on the bus > stop itself. > > In the EU standards they are called 'Stop Points' (rather than Bus Stops) > so they can cover buses, tram, rail, ferry planes etc. > > In railway stations there is a Stop Point for each Platform (and each bay > in a bus station, each Gate for an Airport and each quay in a Ferry > terminal). > > Groups of local Stop Points (as they are called) are then arranged into > Stop Areas where they are very close to each other. > > These Stop Points are not within the road layer because Stop Points are a > distinct dataset managed separately; they are then associated with a street, > sometimes using the Street Name and sometimes based on proximity. > > I recommend that we use 'Bus Stop' and 'Stop Point' for this low-level > purpose and construct entities as we need them. > > The database of all these points in the UK is called 'NaPTAN' (standing > for 'National Public Transport Access Nodes'), there are about 350,000 of > them, and keen people can find additional information here: > http://www.naptan.org.uk/ > > > A new CEN standard is in the process of being ratified, called IFOPT which > can be used for describe much more complex transport interchanges, such as > major airports and railways stations, detailing every corridor, lift, > check-in desk escalator etc. CEN standards are used throughout the EU and > beyond. > http://www.naptan.org.uk/ifopt/ > > > There is also a modelling standard for public transport in general > published by CEN called transmodel which covers the modelling in general and > is used behind most professional transport products used in Europe. > www.transmodel.org > > Of course, I am not proposing that we 'implement' all of the above, but > where we choose modelling approaches and terms for entities it would be > sensible to choose the same names. > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Highway tagging in the USA
What you have on the highway tag (which I may move to a usage page) looks fine to me. I couldn't give you an opinion on how to apply them to roads in California because I've never been in that state. I drove a truck for awhile in the US and there are quite a few roads that won't fit nicely into those categories. That's OK. Just make sure that the highway tag represents what the road looks like in general. Later you can add tags for number of lanes, size of shoulder, shoulder type, divider type, etc. I don't know how the rendering rules work exactly. I would like it to use the highway tag if other data is not available. I remember a state highway that looked like an Interstate except that it had turn lanes and stop signs for the traffic on the crossing roads. I think I would tag it as motorway even though it didn't have ramps. On Tue, Apr 22, 2008 at 3:46 AM, Peter Miller <[EMAIL PROTECTED]> wrote: > I thought it might be useful to have a concrete (literally) example of > USA tagging to talk about. So…. think I have tagged the highways from San > Francisco down to San Jose as described on the highway tagging page, with a > few exceptions. My reference was the international section of the highway > tag article: > http://wiki.openstreetmap.org/index.php/Highway_tag_usage#International_equivalence > > > > The exceptions are as follows: > > > > 1) I upgraded the Golden Gate Bridge from primary to trunk, but I think it > should be motorway because it has ramp-only access. > > > > 2) I upgraded most of the 'braided' highways in the San Francisco area and > other main arteries further south to primary. Some of the ones I coded as > primary in the San Francisco area have now been retagged as tertiary. I have > sent am email to the author of these changes to see if the motivation is to > get the roads to render yellow or if I have missed something. > > > > 3) IThere are many roads that are currently still tagged as residential > which should probably be tertiary, secondary or primary and there are of > course many areas of grey between primary, secondary and tertiary, however I > think it would be good to get some feedback and discussion first. Could > people take a look and see if I have got it about right and suggest or > execute changes where required. > > > > Also… please could someone to a 'trial render' of the area using one or > more potential 'USA friendly' colour schemes so we can see what it would > look like. Personally I would be interested in something along these lines: > > > > Orange and wide: Motoroway/trunk > > Yellow and wide: Primary > > Yellow at narrow: secondary > > Fainted yellow and narrow: tertiary > > > > Could this be done off-line and then posted as an image on the wiki for > discussion? Could anyone have a go at this? > > > > Btw, I have been copying some emails from talk onto talk-us over the past > few days but they haven't made it onto the list, not sure why. Possibly it > was because I was not a member of the list (which I now am). > > > > > > > > Regards, > > > > > > > > > > Peter > > > > > > > > > > > > > > > > > > Peter Ito > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Higway tag wiki
I've been working on other projects lately and not been following the latest discussions. While responding to a recent discussion on the mailing list I noticed that there is a lot of duplication between http://wiki.openstreetmap.org/index.php/Highway_tag_usage and http://wiki.openstreetmap.org/index.php/Key:highway I like the idea of having a separate usage page, but if I go back to that then the info from Key:highway needs to be merged, or vis versa if we want to drop the usage page. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere
On Mon, Apr 21, 2008 at 2:05 AM, Peter Miller <[EMAIL PROTECTED]> wrote: > Thanks for that Jeffrey. I agree entirely that rendering should follow > tagging and not lead tagging, > > Am I right in thinking that the synthesis of this discussion is being > added to this wiki page? > > http://wiki.openstreetmap.org/index.php/Highway_tag_usage > I have made no changes to the wiki recently. A few months ago I changed the page to reflect what I found in the discussion. There is also this page: http://wiki.openstreetmap.org/index.php/Highway I suppose we could switch to different tag values like 2ldr for "two lane divided road with ramps". Do we need a whole new tag? The wrll tag for "what road looks like"? Will changing the tagging scheme increase data accuracy enough to make up for the hassle? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere
On Sat, Apr 19, 2008 at 1:15 AM, Peter Miller <[EMAIL PROTECTED]> wrote: > > Major non-interstate highways that have traffic light free multi-level > junctions etc should be tagged as 'trunk' and possibly also be rendered > orange but with less grand route numbers to differentiate them from > interstate routes. > This statement really bothers me. First, we must make every effort to keep the data separate from the rendering. Consider a section of Interstate Highway that structurally resembles a UK motorway. This section of road may also be part of a state highway. It's not uncommon for a section of road to have both a state highway sign and an Interstate sign. In some very barren areas an Interstate may have standard intersections without ramps. As in your example above a road that is not an Interstate may have multiple levels and ramps. Whatever scheme we agree on must keep the road's structure separate from legal classifications. I checked and the wiki still says that the highway tag should be used to indicate what the road looks like. My reasoning can be found on the talk page. Whether a road is an Interstate, state highway, county road, etc. should be indicated in another data field. I haven't been following all the conversations lately, but I remember an Australian was tagging a gravel road as a motorway because it was the main road between two rural cities and he wanted it prominently rendered. Perhaps in this case some kind of importance tag should be used. I think free tagging is great, but we should not allow multiple definitions for each tag. A tag should not indicate both it's legal status and it's structure, although one might imply the other under certain circumstances. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
