[OSM-talk] Unknown road classifications
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
Re: [OSM-talk] contours on main map
On Thu, 8 May 2008, Robin Paulson wrote: alternatively, are there any world wide maps out there with contours and osm data, that update regularly? The cycle map and the piste map both have contours for selected areas. I'm generally doing monthly updates to the piste map data. As far as I know, no one is serving contours for the whole planet - there are a couple of reasons: 1. The SRTM3 dataset for the whole planet is pretty huge once it has been processed into contour lines and put into PostGIS (probably about half a terabyte). 2. It isn't as simple as just rendering the same contour lines everywhere - for example, the piste map uses much wider spaced contour lines than the cycle map because the terrain is (generally) more mountainous. To make a global contour map you would need to make the renderer vary the number of contour lines used depending on how mountainous the terrain is. Also, whilst having the ability to turn on contour lines would be useful, I certainly wouldn't recommend having them on by default since the tiles are usually quite large compared to the average contourless tile (so a bigger bandwidth bill, more disk space needed for the tile cache, slower navigation around the map, etc). - 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
Re: [OSM-talk] contours on main map
On Thu, 8 May 2008, Robin Paulson wrote: maybe i'll do it myself; some transparent png laid over the top of the osm tiles can't be so difficult Have a look at: http://wiki.openstreetmap.org/index.php/Contours This tells you how contour rendering has been implemented on the piste map and cycle map. - 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
Re: [OSM-talk] [tagging] Road crossings proposal - status?
On Wed, 7 May 2008, Martijn van Oosterhout wrote: Heh. While in london someone tried to explain to me what was so special about all these crossing types. They have names for crossings that here in NL would normal. A crossing with a separate light for bikes, that's like every crossing in NL. All sorts of variations. I don't think I've ever seen a crossing for horses, they just cross. It seems to me that instead of referring to a crossing by name, we should just list its properties. e.g. comething like: highway=crossing crossing=uncontrolled|traffic_signals island=yes|no bicycle=yes|no foot=yes|no horse=yes|no That way you don't need to know about the specific types of crossing (which vary from region to region anyway) - the properties of the crossing are pretty obvious from just looking at the tags with no further knowledge needed. The various (UK specific) crossing names do give you further information such as whether the signal lights are on the near/far side of the road, whether it does anything to detect the presence of pedestrians on the crossing, etc. But if people think this level of detail is important, those sorts of properties can also be added as individual tags. For the record, the common crossings in the UK are: Toucan crossing (Two-Can): cyclists and cycle across at the same time as pedestrians walk across. The lights show both a green bicycle and a green man on the far side of the road, which is activated by a push-button with a time delay. Puffin crossing (Pedestrian User-Friendly INtelligent): pedestrians only (obviously cyclists are considered pedestrians if they are walking with their bike instead of cycling). The lights show a green man on the near side of the road, which is activated with a push-button with a time delay. These also detect the presence of the pedestrian so that the lights won't change if the pedestrian is nolonger there (e.g. the pedestrian crossed early). They detect the presence of a pedestrian on the crossing so they shouldn't turn green for the traffic while you are still crossing. Pelican crossing (PEdestrian LIght CONtrolled crossing): pedestrians only. The lights show a green man on the far side of the road, which is activated with a push-button with a time delay. Pretty-much the same as a Toucan crossing, but cyclists can't ride across it. Pegasus crossing: Like a pelican crossing, but for horse riders. They have two push-buttons at different heights so that horse riders can reach them easilly. Instead of a green man on the far side of the road, they have a green horse. Zebra crossing: Pedestrians always have the right of way. (Wikipedia has some fairly good descriptions of these). - 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
Re: [OSM-talk] [tagging] Road crossings proposal - status?
On Tue, 6 May 2008, Andy Allan wrote: [2] Another brilliant example of how people make themselves feel useful by doing the trivially easy bit, c.f. tracing from Yahoo with no intention of naming the roads. I'm just going to voice an opinion (feel free to ignore it :) - putting roads on the map by any means (e.g. wandering with a GPS, tracing Yahoo, etc) is always very useful, even if one doesn't name the roads: 1. If you're doing something like route planning, you don't need to know all the names of the roads - just knowing that you can get from A to B via this road is useful (although some information about the quality of the road is required so you don't direct HGVs up a tiny 1-track lane :) 2. If the road is on the map it becomes much easier for people who are familiar with the area to fill in the details such as the name - no equipment is needed (such as GPS), they don't need to get off their backside and go out to walk/drive the road and there is next to no effort in putting a name on a road if you know the area. I can see that in many cases, _users_ (i.e. people who just want a map and would otherwise just be using Google) might be happy to add names when using the map themselves, but aren't going to spend the time and effort tracing roads from Yahoo themselves (for one thing this involves somewhat more experience with how OSM works than just adding a name). Chris Jones (who runs the Welsh language OSM) has been working on an AJAX thing to make fixing road names easy without having to understand the editors - I see this as a really good thing since it gets more people contributing to the project, but it does require that the roads themselves are in the database. - 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
[OSM-talk] Track offsets
I've come across a problem with one of my methods of collecting tracks - I'm hoping someone might have some input: I've got a computer in my car which connects to my (old style) eTrex Venture GPS via a serial cable. The computer runs gpsd to talk to the GPS. It also runs Kismet which does things like logging 802.11 networks, but most importantly Kismet talks to gpsd and logs the GPS track. I then process the .gps file Kismet produces into a GPX file to use with OSM. Now the problem - I recently compared the track downloaded from the GPS itself (using gpsbabel) with the track produced by Kismet and found they were fairly consistently offset from eachother by 100m or so. I haven't worked out where this error is being introduced yet, but the GPS is set to WGS84 so I would expect the NMEA stream and the GPS's tracklog to match. My next step is to look at the NMEA stream itself and see if that is correct, but has anyone else here had any similar problems that could shead some light onto what is going on? - 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
Re: [OSM-talk] OSM in Europe Statistics
On Wed, 30 Apr 2008, Frederik Ramm wrote: Of course this is very simplistic and I believe you will come up with much better measures of progress. Let's hear your numbers ;-) Interesting numbers. I suspect objects per capita would be more meaningful than compressed bytes though (but more effort to calculate, of course :) - 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
Re: [OSM-talk] Climbing routes
Chris Hill wrote: Leaving the namespace issue aside, how would one collect the information about climbing routes? The routes I climbed didn't have signs or the like to gather from the site. All of the climbing guides I have that describe the routes, including their name, grade, number of pitches etc are copyright. Are there copyright free sources of this information? The information I put on the one route I've done so far came from common knowledge amongst the local climbers. Of course the local guide book also contains the same information, also gleaned from common knowledge so it is a rather fuzzy issue when you start to question where the original information came from, whether it can even be copyrighted by anyone, etc. I don't think the problem is a lot different to normal mapping though - if you ask someone what is that road called (maybe it doesn't have a road sign) and they tell you, you have no idea if they previously read it off a map, or if the Ordnance Survey asked the same people the same question (thus their map contains the same data), etc. Seems a difficult question - at what point does copyright end and common/local knowledge begin? Some of the information is hard fact though - if you've climbed a route then you can estimate its length, etc. -- - 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
Re: [OSM-talk] namespaces and copyright
elvin ibbotson wrote: Chris Hill is worried about copyright issues with climbing routes and this is like lots of concerns I have seen expressed such as taking street names from actual street signs rather than from copyrighted material. If it's the name of the street, it's the name of the street, no matter how or where it is communicated. Street names and data on climbing routes are unfortunately a bit different though. Street names are generally hard fact - there is some government database somewhere saying what it is called, there are signs up with the name on, signs with access restrictions (one way, etc). On the other hand, on a rock face there are no signs - things can become much more subjective. Climbing (difficulty) grades, for example, are estimates - there is no hard fast rule about what makes a route a specific grade. A bunch of people climb it and make a guestimate on how hard they think it is. -- - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Allan wrote: You are taking what you believe to be true, and applying it to everyone else. The same can be said for both sides of this discussion. If you think there is no clear winner, then shoudn't the established conventions should take precendence? There are established conventions for both flat tagging schemes and namespacing - see the likes of the piste proposal, the lighthouses proposal, etc. Otherwise it's just change for change's own sake, and that's a waste of time. Nothing is being changed - these are tags which didn't previously exist. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 24 Apr 2008, Christopher Schmidt wrote: I can't claim to have the right answer, but I will state that it is not common in geographic software to have namespaced attributes: in general, when this is the case, it is a namespace based only on the object type which has a specific schema. (In this case, that would be something like pisteLift, since the dataset would be a list of pisteLifts.) But in common software, do the objects have an explicit type? In OpenStreetMap they do not - the type is determined by a bunch of arbitrary tags, for which you need background knowledge of which tags define the object type and which just define attributes (e.g. there is no unified type tag which you know will always define what the object is). - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 24 Apr 2008, Christopher Schmidt wrote: It almost sounds like the proposal is to use namespaces in place of a 'type' property on the object... which I personally think would be a better way to go than to namespace every tag... The idea is to make the context of the tag much more obvious. This can be done by either using namespaces on the tag itself, or having a method of unambiguously identifying the context of the object itself. I don't pretend to understand what was wrong with the old class system, which seemed to achieve this to some extent. On the other hand, having namespaces in the tag name itself does have the advantage that it gives people clues that they might be using the wrong tag.. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 24 Apr 2008, Dave Stubbs wrote: And if the occupancy is on a fish pond then it likely does How do you know it's a fish pond? There is no tag that unambiguously identifies the type of object it is. Instead there is a whole load of tags to identify the object, and you have to have a lot of background knowledge about the structure of the data to know which tags identify the object type (and thus the context of the other tags) and which tags are just describing attributes of the object. if [piste:lift] is not null and [occupancy] is not null then: print piste:lift:occupancy = [occupancy] wow. that was hard. And also demonstrates how completely pointless the namespace was. How did you know that the piste:lift tag declares the object as being a lift? That's right, you didn't unless you already had an underlying knowledge of which tags identify the context and which don't. This is completely stupid - yes, they might avoid coming up with new unnamespaced tags and *shock* propose new namespaced tags instead. Why is this a bad thing? you snipped the or: they'll attach meaningless drivel to the start of every tag as a substitute What sort of meaningless drivel? which is effectively what you're doing anyway. Except it is neither meaningless nor drivel. What you're doing provides nothing extra: I can throw it away and be left with the same information. No, you can't - if you throw it away you lose the context of the tags. The *only* way to recover the context information is to know which tag to retrieve it from, which is not something you can do from the data alone. Thus you have lost something which is not recoverable from the data you have - you now need to go find an external data set as well. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 24 Apr 2008, Dave Stubbs wrote: It would probably have a tag like man_made=fishpond. I don't know there's a tagging schema for that. How did you know that the man_made tag defined the context? Seriously, I've had enough of this. That's fine, but I'm afraid you haven't convinced me to change my position: name spaces are a Good Thing, and I'm clearly not alone in this belief. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote: For a climbing route it's normally the distance of assent that is of interest is it not and I guess for most traditional climbing routes this is known? Much easier to state the length of the route than the top and bottom elevations? Accepted that you might want to converge on an elevation for the start of the route as accuracy of the position is improved with time. Yes. There is a climbing:length tag in my proposal, but this is not the same as top_elevation-bottom_elevation since the elevations are purely a vertical component whereas the length is the total length from top to bottom of the (possibly not entirely vertical) route. For example, some multi-pitch routes have scrambles in the middle, but would still be considered a single route so the length would include the scrambles (which are nowhere near vertical). At the moment I don't think we have enough data to be able to render a 3D map. Adding SRTM3 data wouldn't help a great deal for this purpose because it isn't nearly high enough resolution to represent a cliff properly. Whilst having good elevation data would be a nice thing to have, the equipment is a bit too specialist for now. Does anyone happen to know how well Gallileo is expected to perform in terms of vertical accuracy? - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote: The point has been made by others that the namespace here is unnecessary. We know what length= means here so the climbing namespace is superfluous because what you are tagging is a climbing route. I'm aware the issue is contentious, but no one has said anything to convince me that namespacing isn't a good thing (certainly nothing showing why it is a bad thing). Start to end of section as one way (there may be more than one section in the route, some climbing and some scrambling etc). I had considered specifying that each pitch (section) must be a different way, but concluded that it probably made things unnecessarilly difficult since you'd end up with a big cluster of nodes and ways in a very small (horizontal) area. Of course, there is nothing stopping people from sticking nodes in the middle of the way if that is sensible for specific routes (i.e. ones with a large horizontal component). climbing routes are no different. They are different in the fact that they have a much greater vertical component and a much smaller horizontal component to almost any other OSM features, which makes handling the data in a 2D environment (such as JOSM, Potlatch, etc) more difficult. This certainly needs to be taken into consideration. adjectival:gb= (assuming the same route at the same location requires alternative country grading, if it only applies within the country where the route is located then the gb would not be required) Only the British system has the separate adjectival/technical grades - other systems have a single grade to describe the route (the exception being YDS, which has 3 separate grades to describe different aspects of the route). It is common to list several different grading systems for the same route as well - for example, in the UK, sports routes are often given grades for both the British and French grading systems. Anything that has lots of namespaces, abbreviations or other non-obvious tagging names makes it much more difficult for data contributors to easily add tags. On the contrary, namespaces make it easier to look up the definitions of tags, etc. since there is no chance of being confused with identical tags from a different context. I really dislike the way that, without prior knowledge, it is impossible to determine the context of the tags if they aren't namespaced. In your example, the context is given by the footway=climbing tag. But the only way you know this is providing the context of the other tags is by some fairly arbitrary prior knowledge - how do you know that the context wasn't provided by the rock=limestone tag instead? Simple and logical appears always to work best. Indeed, I agree. But we differ on what we believe is simple and logical - I think clearly declaring the context of the tag is much more simple and logical than having a mess of identically named tags, potentially meaning totally different things depending on a context provided by another tag which isn't obviously providing the context. If there was a *single* type= tag that always describes the context of the whole object, then I might agree that namespacing is unnecessary, but there isn't, so I don't. :) e.g. type=highway:motorway, type=waterway:river, type=railway:line, type=piste, etc. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote: I'll guess we will agree to disagree then. If it works for you ane the other climbers amongst the contributors then of course you can do what works for you :-) I don't think any other climbers have voiced an interest in tagging routes yet, so I suspect it is just me for now. :) We would be back where we started 3 years go. type is no different from class, the previous method of tagging which didn't scale easily. Indeed. What were the reasons for it not scaling well? I did have a poke around Google but couldn't really find anything on the rationale behind dropping the class system (notably, relations seem to go back to the idea of having a type tag too...) - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote: Because it was difficult for the layman freeform tagger contributor to decide what the root class should be, for instance is it class=waterway or class=river. I think I'd be inclined to try and make things a bit hiararchical - e.g. waterway:river or waterway/river. But really this sounds like a documentation issue more than anything - if there is documentation providing reasonable guidance, and a good set of existing classes all following the same standard, this seems like a good way of doing things. Just going back to namespaces (trying not to nag you), the use of namespaces is very useful in certain contexts, where true separation within a dataset is desirable. My main concern with a lack of namespaces is that you can end up with a single tag key meaning very different things depending on the context it is used in, and the context is not always obvious. This makes interpretting the tag, looking it up in the wiki, etc. a problem. And if you attempt to unify the meanings of these tags so that they are not so ambiguous when you don't know the context, you end up having to coordinate far too many bits of the project. Using a string of namespaces in front of each and every tag (the key getting longer and longer as the data gets more complex) doesn't really in my view give the same flexibility that I think is needed for OSM. To some extent, this is about presentation - if the editors presented this string of namespaces in a nicer way, rather than just a big string of namespaces then it would suddenly become much nicer to work with. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote: As I think AndyA pointed out you are not normally looking at a tag out of context, e.g. on its own without any of the other tags applying to the same feature. The problem is that the context isn't clear since there is no designated context tag - i.e. if you have a way tagged with highway=climbing and rock=limestone, is the context provided by the highway tag or the rock tag? Standards wanking aside there is I believe some benefit in evaluating the way tags are delivered in xml output so that some hierarchical information can be relayed. At present there is no logic to the xml delivery of tags and perhaps users of the xml data might benefit if there were. Presenting hiararchical data in the XML is going to require some kind of adjustment to how things are tagged in the database (whether this is simple foo:bar:baz namespaces, or some rather deeper change to the underlying structure of the data). - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Cartinus wrote: A machine wouldn't know without a set of rules or a hierarchy. Isn't part of the point of OSM to produce a data set that _is_ machine readable? I consider lack of machine readability to be a real problem. plus it is filled with lots of background knowledge. I think the context is only obvious to those who have been dealing with the structure of the OSM data set for some time. Once again you have removed the context from your example I have said the source of that context can be extremely ambiguous. This is not the same as removing context - it is simply that you can't necessarilly identify the context. This is a problem. * with a certain purpose And what is that purpose? * shown in an editor Not necessarilly. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Wed, 23 Apr 2008, Andy Allan wrote: You are clearly unwilling to consider the downsides of your namespacing proposals, beyond pure technical matters I am trying to think about all aspects of the proposals. However, so far the only argument against them seems to be that namespaced tag names are difficult for people to use. This is something I truely can't understand - I would think that anyone would find more meaningful and non-conflicting tag names to be easier, not more difficult to use. It is possible that none of us are the people to work out what is actually easier for contributors - the newcomers (possibly the less technical ones) are the people to ask. Unfortunately I can't think of a good way of polling them for an opinion since it is generally the more seasonned people who hang out on mailing lists to discuss this stuff. :) Perhaps one day I'll meet you over a drink and we might be able to get somewhere! It is always possible. :) In the meantime, I'd ask you to respect the views of the other people that have contributed to the discussion, especially when providing tagging guidelines/proposals on the wiki. I certainly respect all the views which have been voiced in the discussion. However, given views on both sides I don't think there is a clear winner so I see no immediate reason to change the proposal (especially since the people arguing against the current proposal are probably not the people who will be contributing and using this data). As always, things on OpenStreetMap are fluid and the proposal can be adjusted at a future date in light of new requirements / opinions / experience. I am fairly sure that as support for relations becomes better in the editors, the way data is tagged will change dramatically anyway. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Mon, 21 Apr 2008, OJ W wrote: Perhaps the ele=x m tag would be useful here - so that if someone actually tries creating a 3D map of a crag they'll have data to work with... I'm trying to avoid requiring the ele tag because elevation data is hard to get (accurately). However, if someone has the equipment and wants to add ele tags then all the better. - 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
Re: [OSM-talk] New Export Tab
On Mon, 21 Apr 2008, Tom Hughes wrote: With the mapnik bitmaps formats, if you assume the bitmap to be a 96 DPI image then the scale should be what you asked for I think. It might be worth mentioning this on the export page itself. In any case, excellent work. I'm going to have to start investigating the use of the main OSM codebase for the OpenPisteMap website - things like the export tab would be extremely useful there. - 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
Re: [OSM-talk] OSM for mobile web pages?
On Mon, 21 Apr 2008, Frederik Ramm wrote: Tiles are 256x256 pixel. If you want decent usability you must display three columns and three rows and then always pan by +/-1 otherwise the user gets confused. You could try to simply display one tile but I doubt this will work well. I think Google's just displays one tile. Of course, we don't just have to do what Google does. :) Displaying a 256x256 tile, but being able to scroll the map half a tile at a time would work better, but is complex (probably requires rendering a whole extra set of tiles) - 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
Re: [OSM-talk] Dhaka is under water!
On Mon, 21 Apr 2008, Francois De Ryckel wrote: AS I was working on Dhaka (Bangaldesh) I deleted by mistake some nodes that belong to some coastline drawing Consequences: the whole Dhaka is now under water! (I know is pretty common but it isn't now the rainy season ... 2 more months!) Any way to repair that mistake... Select the coastline in potlatch, hit H and revert the change. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
Tom Hughes wrote: Because the name tag is always the name of an object, regardless of what that object is (the amenity=pub tells you what sort of object it is in this case). It is clear to everybody that a name tag is going to tell you the name of something without having to know anything else about it. Yes, I think this is a very good way of looking at it. Tags such as the name tag have a global significance - they apply to (almost) all contexts in the same way. There are very few of these global tags (in fact I'm not even convinced ref should be considered global). Most other tags only apply to a small number of contexts, so they become more meaningful if the tag includes a namespace. Often the same tag will carry quite different meanings in different contexts, which means that when taken out of context, the tag becomes very ambiguous. I think we really want a situation where you can just look up a tag to find out what it means, rather than having to work out which of the many definitions apply. -- - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 17 Apr 2008, Chris Hill wrote: I simply don't see namespaces as necessary. In this case I'd draw the building and label it as a supermarket, then add a node for the post office. This seems a very messy solution to me. The building is a supermarket, the post office is only part of it. That may not be the case - I know of several buildings which have several different shops in their own right within them, which should all have equal status. The post office may *not* just be part of the supermarket - it may be a completely separate thing within the building. Other examples include things like: buildings which have both toilets and showers within them, bus stops and post boxes that share the same pole, etc. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Fri, 18 Apr 2008, Robin Paulson wrote: structure=pole highway=bus_stop amenity=post_box Ok, but you still have a potential conflict here. Hypothetically, you could have a timetable tag which applies to both a bus stop (tells you when busses arrive) and a post box (when is the post collected?). A neat solution is to have bus_stop:timetable and post_box:timetable. a lot of the disputes over tagging are caused by people confusing physical items with conceptual ones; if we thought about separating them before debating a tagging scheme, things would be a lot clearer That may be, but I still think in some cases you are going to want multiple conceptual items attached to a single item - namespacing allows this to be done without risk of conflicting tags and makes it more obvious how the tags interact with each item (conceptual or physical). The same thing _could_ be done with relations (i.e. you mark up the physical items with ways and nodes and use relations containing physical items to represent the conceptial things). But at the moment that would be even more complex than a clear set of namespaces. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Fri, 18 Apr 2008, Andy Allan wrote: Ah, I see the problem. You are taking a tag away from it's context, and then complaining that the tag has no context on its own. Only part of your argument is based around conflicts, but the rest seems to be context. Yes, it's a bit of both - I think these are two separate problems with the flat name space. How do I tell that name=The Duke's Head refers to the name of a pub? I don't feel the need for amenity:pub:name= and highway:primary:name= in order to solve this issue. Instead, I examine the context of the original tag, and find that it is the name of a pub. Actually, I would prefer to see everything namespaced, such as amenity:pub:name or pub:name. But clearly that isn't going to happen any time soon. In my ideal world, the editors would allow the user to attach a hiararchical tree of tags to an object, which would do a wonderful job of identifying the exact context of each tag. :) This is where people run into problems on the wiki - you can't explain the meaning of the tag capacity in its own right, but you can in the context of car parks, bike parking, football stadiums and ski lifts. The wiki problem would, of course, be fixed if all tags were prefixed with the appropriate name space :) But this is still not an argument for namespaces, when we have other options (yes, relations) available But relations are even more complex for people to understand and use than namespaces (which seems to be one of the primary arguments against namespaces)... So in summary, I think the need for namespaces is driven purely by people who want to view a tag in isolation yet still want to have context, when what they should do is not remove the context in the first place. Part of the problem is that you need prior knowledge as to where the context comes from. OSM treats all tags as equals, but in reality they aren't - for example, a highway=motorway tag immediately defines the context for all the other tags as being something to do with motorways. amenity=pub defines the context for all the other tags as being something to do with pubs. But name=Station Road or ref=M4 doesn't really change the context. Without having prior knowledge about which tags are defining the context, and which are just providing data, it is sometimes quite ambiguous where the context comes from. On the other hand, a clear namespace such as highway:motorway:ref=M4 makes it immediately clear what the context is. This makes it easier to do something like look up a tag in the wiki, to work out what it means. - 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
[OSM-talk] Tagging climbing routes and scrambles
There isn't much guidance on how the sport=climbing tag should be used when dealing with outdoor features. What exactly should be tagged with sport=climbing? Possibilities include: * The crag (probably a node, or maybe a way following a cliff, or an area) * The start locations of individual routes (nodes) Marking individual routes may be tricky in some cases (e.g. if they are close together or share the same start location), but could be very useful when routes are more spread-out. There are also potentially useful pieces of information about the routes which could be recorded, such as the grades. Also, is tagging a scramble as scramble=Grade 1, etc. the recommended way of doing it? Crib Goch seems to be tagged like that (and [EMAIL PROTECTED] renders it), but there is no mention of it in the wiki: http://www.openstreetmap.org/?lat=53.07684lon=-4.05342zoom=16layers=0BFT - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 17 Apr 2008, Nick wrote: It's worth noting that in terms of climbing grades there are plenty of different systems worldwide to allow for: Yes, I was considering having a tag for each. e.g.: climbing:grade:british:adjectival=VS climbing:grade:british:technical=5b climbing:grade:french=6a etc. Although this makes the tag names rather long. Isn't it funny how in the last few months there's been lots of activity in terms of piste mapping - and now the weather has become nicer in the UK, the sport of climbing takes its turn... :) Well, it's all good stuff anyway - the wider the variety of data we collect the more people OSM will appeal to. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 17 Apr 2008, Andy Allan wrote: And full of frigging namespaces. Yes - I consider this a Good Thing. Please, please don't let the stupid Piste namespacing infect your brain and make you wander round with a namespace-hammer looking for new tagging-nails. I'm afraid I consider the piste (and other features) namespacing to be extremely sensible, and the completely flat namespacing being used elsewhere to be really stupid. Namespacing makes it much more obvious what a tag is referring to and allows you to mix and match *any* features on the same objects. This is a Good Thing. I *really* dislike the idea of making decisions about which tags might conflict with eachother and which might not - we can't see into the future. If you namespace everything then the problem of conflicting tags goes away, if you decide not to put namespaces on tags you don't think will conflict then you end up in a complete mess in the future when it turns out something you want _does_ conflict. british_trad = VS british_tech = 6b french = 6a Does the trick, nice and simple, no problems. But makes it less obvious to people who don't have a good knowledge of climbing as to what the tags mean. If you have climbing:grade:french it is obvious to *everyone* that this is some kind of grade for climbing - a tag called french really does fall into the non-obvious category. I understand that various people have an objection to namespacing because it is perceived to make things harder, but I'm convinced that if it is harder (and I, personally, consider it much easier) then this is something to improve in the editors, not something to prevent in the database itself. - 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
Re: [OSM-talk] Tagging climbing routes and scrambles
On Thu, 17 Apr 2008, Chris Hill wrote: The only person likely to tag climbing routes is someone who understands climbing routes ;-) What about someone just trying to interpret the data stored in OSM's database? It should be obvious what the data is, without having to start looking stuff up on the wiki (where it may not even be documented). plain, sensible tags +1 Does french count as a sensible tag now? - 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
Re: [OSM-talk] Namespaces (was: Tagging climbing routes and scrambles)
On Thu, 17 Apr 2008, Ben Laenen wrote: There's currently no way to properly tag those kind of restrictions, unless I've missed something... Maybe what is needed to satisfy everyone is *optional* namespaces - if you don't specify a namespace then it is assumed to apply to all of the namespaces (unless overridden by a tag containing a namespace). - 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
[OSM-talk] Rocky beaches
I'm attempting to trace some of the Gower coastline from the (very fuzzy) Yahoo images. But I'm not sure how to tag beaches made up of flat rock. For example, the type of thing shown by this Google aerial view: http://maps.google.co.uk/maps?f=qhl=engeocode=jsv=107ie=UTF8ll=51.561598,-4.302907spn=0.003855,0.015836t=hz=16 And photograph of the same location: http://www.nexusuk.org/photos/other/gower/2006/04/15/img_3465/view I don't really want to tag it with just natural=beach since that would imply a sandy/shingle beach (i.e. something nice for bathing on), but I can't really see an appropriate tag. - 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
Re: [OSM-talk] Rocky beaches
On Mon, 14 Apr 2008, Stefan Baebler wrote: natural=scree perhaps? Scree refers to steep slopes covered with loose stones - this is (very uneven) horizontal solid rock. - 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
Re: [OSM-talk] Rocky beaches
On Mon, 14 Apr 2008, Matt Williams wrote: From the proposal at http://wiki.openstreetmap.org/index.php/Proposed_features/Water_cover it seems that natural=beach, surface=rocky (or surface=rock?) and optional water=tidal tag if you feel like it :) Excellent - that seems to be a good answer, thanks. Although I note that the proposal doesn't mention whether it should also be tagged as natural=beach (how do we actually define a beach? It's rather a vague idea). I've also raised a question on the natural=coastline talk page about what the coastline actually denotes - I can't see anything saying whether it is the high water or low water line (I'd assume it's the low water line - i.e. everything to the right of it is always sea, no matter what the state of the tide, whilst stuff to the left of it is assumed to be land (tagged as water=tidal if it is flooded at high tide). - 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
Re: [OSM-talk] Rocky beaches
On Mon, 14 Apr 2008, Chris Hill wrote: High and low water marks vary every day, the height of the tides vary a lot.. Correct - anyone who records high and low watermarks on maps/charts will be using the highest and lowest astronomical tides, not the high/low tide of an arbitrary day. Most measurements are made using Mean Sea Level, which doesn't change (rising sea levels aside). The options are generally to record lowest, highest or mean watermarks. ISTR that Ordnance Survey mark all three on their Explorer maps don't they? And maritime charts rarely (never?) bother with mean - they are marked up in heights above/below lowest astronomical tide. When you look at the Yahoo images, how do you know what state the tide is? You don't (other than being able to guestimate based on local knowledge). However, in some locations the coast line data is quite inaccurate and can be approximated by hand based on local knowledge and the Yahoo images. Some of the beaches around here (Gower, South Wales) are very flat and the very large tidal range of the Bristol Channel means the distance between high and low water marks can be over a kilometer. At the moment, nothing states what natural=coastline is actually supposed to be documenting, so when estimating the coastline by hand you have no idea whether to put it at the top of the beach, at the bottom of the beach or somewhere in the middle. I'm not expecting to be able to record the coastline with a huge amount of accuracy, but even an estimate is more accurate than the (big) distance between high/low water marks in some locations so defining what we are recording is important. - 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
[OSM-talk] Unexpected :)
That's rather unexpected: http://geo.topf.org/comparison/index.html?mt0=googlemapmt1=mapniklon=-122.084187lat=37.42216z=17 :) - 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
Re: [OSM-talk] Unexpected :)
On Thu, 10 Apr 2008, maning sambale wrote: Well, they do censor their images, http://en.wikipedia.org/wiki/List_of_places_blurred_out_on_Google_Maps Why not, in their streetmaps? Dunno.. I just didn't expect them to censor their own offices from their own map :-/ - 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
[OSM-talk] Tagging crags (sport=climbing)
The only thing I can see in the wiki for tagging crags is sport=climbing - has anyone been tagging any crags with more information? If so, what tags are you using? - 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
Re: [OSM-talk] Mapnik: amenity=bus_station
On Tue, 8 Apr 2008, Niclas Andersson wrote: I've always used a node in the way to represent a bus stop. This works fine when there's a stop on each side of the road. Otherwise I've made use of the bus_direction=(N|S|E|W) tag (from http://wiki.openstreetmap.org/index.php/Buses ) on the node to indicate in which direction the stop is for, which I believe should work fairly well. Ah, I hadn't come across the bus_direction tag - that looks like a good solution. Thanks. - 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
Re: [OSM-talk] Mapnik: amenity=bus_station
On Tue, 8 Apr 2008, Cartinus wrote: Up till now I used the node in the road method. But lately I have been thinking about how routing applications would use osm data. I doubt bus companies will be using osm to route their busses. But when routing for pedestrians, you will want to be able to reach the bus stops. Bus companies may not want to to use it for routing, but someone else might want to run a route planner for getting from A to B by public transport and on foot (there is one run by the UK government already I think?). This would need to take account of bus stop location, direction as well as data from other sources such as bus timetables. I think this is the one I was thinking of: http://www.transportdirect.info - 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
Re: [OSM-talk] Mapnik: amenity=bus_station
On Wed, 9 Apr 2008, Steve Hill wrote: I think this is the one I was thinking of: http://www.transportdirect.info No, sorry, it was probably http://www.traveline.org.uk/ - 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
Re: [OSM-talk] Relations not always brilliant
On Tue, 8 Apr 2008, Lester Caine wrote: How DO we currently identify all roads in the UK, so that we don't end up with some of the simply silly links that the likes of Autoroute returns when asking for a location. We need a consistent UNIQUE index method that will allow all 'ref=M11' elements in the UK to be identified as that one element. Why do we need them all to be identified with a single element? You cite route planning as a reason but I really don't see why it is applicable - your route planner doesn't need to know that two bits of road with a gap between them are (administratively) the same road. In fact, there are only 2 times a route planner needs to know about the road's ref or name: 1. When producing instructions (Take the 3rd exit onto the M11) 2. As you cross from one way to another in order to determine if it is really a junction or just a continuation of the same way (you don't want it to tell you to continue along the M11 at arbitrary points just because the way has been split there, and you might want to impose some kind of penalty for turning off the road to prevent the route from containing too many small turns). Putting all of the separate bits of the UK's M11 in a single relation sounds about as silly as putting all the roads in the UK called Station Road in a single relation - they are separate roads and there is no good reason to treat them in any other way. - 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
Re: [OSM-talk] Mapnik: amenity=bus_station
How are people tagging bus stops? I have been setting tagging nodes that are members of the way, which means they are part of the road they are on. Is this the right way to do it? It seems right since it unambiguously shows which road the stop is on, but it doesn't allow any indication as to which side of the road the stop is on. - 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
Re: [OSM-talk] Relations not always brilliant
On Tue, 8 Apr 2008, Robert (Jamie) Munro wrote: You don't think that searching for M11 should produce one result for a road that covers the whole country, and searching for high street should produce hundreds of separate results? But a motorway which is not a continuous road (i.e. has gaps in it) is _not_ a single road - I see no reason why it should be treated as one. Maybe you could cite some examples of why you need to treat it as a single road, even though it has gaps in it? - 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
Re: [OSM-talk] Mapnik: amenity=bus_station
On Tue, 8 Apr 2008, graham wrote: I have mapped quite a few bus stops where the bus stop is on a pedestrian island and I want to show not only 'side of road' but also a fairly exact physical position. I'd be reluctant to give that up to plonk all my bus stops in the middle of the road... Sounds like a job for a relation (but there are quite enough relation arguments going on at the moment :) - 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
Re: [OSM-talk] Relations not always brilliant
On Tue, 8 Apr 2008, Andrew McCarthy wrote: (2) A relation for that road's notional route, that contains the relation above *plus* the (usually obvious) connecting bits that give you a single, long distance route from A to B. Which bits you use to connect the disjointed sections are a rather arbitrary decision - should OSM be making such decisions? I mean, there is no officially documented this is how you get between these sections route so we would be making a route up arbitrarilly. Sure, for some stuff it might be obvious, but for a lot of stuff it isn't. Take the A31, for example - it joins the M3 near Winchester but then reappears on the westerly end of the M27. You might say that the M3 and M27 is obviously the missing link and add that to the A31 relation, but that would be completely unsuitable for cyclists. This really isn't the job for submitters, this is the job for a route planner program - submitters are supposed to be recording data, not making relatively arbitrary decisions about which routes people should take. - 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
[OSM-talk] Maplint warnings
Maplint seems to be throwing up not-in-map_features warnings about stuff that is on the Map Features page. For example: http://www.openstreetmap.org/?lat=51.68309lon=-3.91837zoom=15layers=0BTT There are warnings for the direction=clockwise tags on mini roundabouts, power=tower nodes and power=line ways. - 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
Re: [OSM-talk] Relations not always brilliant
On Tue, 8 Apr 2008, Andrew McCarthy wrote: In that case, would the use of highway relations be restricted to such cases where there is one *official* route, with differing refs? Official by whose authority? I am not aware of the UK highways agency publishing official routes for these gaps (although for other countries there may be some kind of official route - a relation with the route= tag may be a reasonable approach if there really is something official). For example, National Primary Road 7 in Ireland is the entire road from Dublin to Limerick. It's called the N7, but for those portions where it's a motorway, it's the M7. In this case ref=M7;N7 would only be appropriate for the motorway if N7 was guaranteed not to appear. Is the M7 officially also the N7 though, or are you just making a decision based on a subjective obviousness criteria? - 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
Re: [OSM-talk] Relations not always brilliant
On Tue, 8 Apr 2008, Andrew McCarthy wrote: It's specified in the Statutory Instrument issued by the Government. I've no idea if we're unique on this, but it's a big planet :) Sounds like ref=M7;N7 is the correct thing to do in this case then. As for what the renderers should do, that's another question (there could be arguments for showing an M7 label with N7 under it in smaller type, etc. but so long as the data is in the database in a useful form, that can all be worked out later). - 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
Re: [OSM-talk] Relations not always brilliant
On Sun, 6 Apr 2008, Richard Fairhurst wrote: In the UK, road numbers are unique (apart from about three cases where local councils have cocked up, e.g. the B4027) This isn't entirely true - take, for example, the A31, which goes from Guildford to Winchester and then vanishes as it joins the M3. It then reappears on the Westerly end of the M27 and continues to the West (the A35 does a similar thing, as do quite a lot of other A roads). C roads, of course, are not unique (but their reference numbers tend not to be published). and no road can have more than one ref. I believe that might also be untrue. It doesn't excuse the use of relations though - multiple refs should be specified like: ref=Bfoo;Bbar The relation doesn't give any info over and above that in the standard 'ref' tags - it just increases complexity for both editing and processing. I agree entirely. Presumably the idea of the relation is to allow routing algorithms to rejoin ways which have been split, but this isn't necessary - if the end of 2 ways share the same node and they have the same ref then they can be rejoined. The existence of multiple non-adjacent roads with the same ref doesn't change this and the existence of multiple refs for the same road only adds a minor complication. - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, Frederik Ramm wrote: Which will omit anything tagged ref=B4027;B4028 or some such. Ok you said there shouldn't be any of those in the UK anyway so I guess you're fine... Then the API needs to be improved - we shouldn't be adding unnecessary data to work around deficiencies in the API. I think it is a good idea to group objects that belong together in a relation. Ultimately I'd expect the relation to carry the ref=B4027 tag and to drop that tag from the ways contained therein. Makes a lot of sense from a data modelling viewpoint I think. I am concerned that it adds complexity (which means there is more chance of human error). Complexity in some cases is unavoidable, but in this case I can't see a significant advantage over just tagging the ways and improving the API to allow searching for single values in multi-value tags. - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, David Earl wrote: And to take the A11/A14 example again, if the A11 in effect disappears where it is coincident with the A14, the A11 is discontinuous. I'm not sure why we need to treat the whole discontinuous A11 as a single road. In this example, as far as I can tell we have 2 roads called the A11 and a road joining them called the A14 - route planners can deal with this just the same as they can deal with A11 - A14 - A134. Route planners shouldn't be directing you along the A14 just because it happens to also be part of the A11 - they should be directing you down it because it is the best road to get you from A to B. - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, Frederik Ramm wrote: If it's done consistently, one can still create relations automatically later if desired. But this is kind of the point - if you are able to automatically create the relations (and presumably automatically fix them if someone makes the way tags inconsistent with the relation tags) with very little effort, is there a good reason to create them in the first place rather than deriving that data as and when you need it? - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, Frederik Ramm wrote: I assume it will usually be easier to check a machine-readable relation than to compare tags. Possibly. There may be cause for having machine generated relations which are kept up to date by the server when data is committed so the people editing the data don't need to care about them (such relations would need to be read-only and tagged in a way to make it clear they aren't normal editable relations). I think that'd be easier for people submitting the data than having to deal with these relations directly (which as you say, are only there for efficency reasons) In the end, moving *all* tags into relations might be the best thing to do, but I think the editors need a lot of work before that is a viable option. At the moment we have a rather confusing mix. it seems unnecessary to ask them to also group by tags which involves finding out which tags to group by, which bounding box so search in, splitting tag values at semicolons etc. Unless you can ensure that the relations exist on *all* appropriate objects, they will have to group by tags anyway. (And I don't believe you can ensure this without some automatic daemon fixing up the relations on all the data as it is submitted). Rather than have one million systems implement their own ways of guessing what was meant, I'd like to put this explicitly in the database (or at least have *one* central system do the grouping consinstently). This sounds sensible. But as mentioned, I think for it to be achieveable we either need a lot of improvement on the editors to make relations more obvious and intuitive, or we need some automatic stuff to generate the relations that can be unambiguously derived from other data. (Or both) I'm concerned that the data structure might be outpacing the editors too much and this could be raising the bar to entry for mappers. But this discussion is becoming much too theoretical. Well yeah, but sometimes it's good to bash theoretical ideas around to see what works. :) - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, Stephen Gower wrote: Suppose I wanted to walk the whole of the A34 while I was 34 as a charity gig? Ok, either: 1. You have lots of ways tagged with ref=A34 2. You have lots of relations tagged with ref=A34, one for each discontinuous section of the road (which may be multiple ways) 3. You have a single relation tagged with ref=A34, containing all of the ways making up the A34, but with gaps where there are discontinuities. In the case of (1) the API needs some work to make it possible to search for single values in multivalue tags. You can then search for ref=A34 and get a list of ways back. For (2) you can search for ref=A34 and get a list of relations (and therefore a list of ways). For (3) you can search for ref=A34 and get a single relation (and therefore a list of ways). In all of these cases, there is nothing especially non-trivial. You might get a performance improvement from (2) and (3) since you don't have to parse so many tags (and the parsing isn't as complex since they only have a single value in the tag). But (3) doesn't seem to be better than (2). Whichever method you have taken, you end up with the same data - a list of ways with gaps in them where there are discontinuities. You must fill in those gaps yourself (e.g. using a routing algorithm) and OSM can't do this for you. Different people will have different preferences for how to fill in those gaps - car drivers may prefer motorways whilst you, on your walk, probably want a shortest-distance non-motorway route. You may even choose to reference third party data, such as land elevations to allow you to go around large hills instead of over them. OK, that's contrived, but beware of arguments that apply to just one use-case (for what its worth, I'm undecided about if relations in this situation are brilliant or not brilliant). Noted. But I still haven't seen any good explanation as to why we need the whole of a discontinuous road in a single relation. The only good reasoning I've seen for using relations at all is for performance and consistency reasons (which are good points, but I don't think that requires a discontinuous road in a single relation - if we stick to continuous roads in each relation then the relation generation can be automated, which would ensure consistency, reduce the scope for human error and make data submition easier.) - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, Robert (Jamie) Munro wrote: It might not be the A11 from the point of view of who is in charge of maintaining it, but it is the A11 from the point of view of someone following the route of the A11 to get somewhere. Therefore it should be in a relationship as part of the A11, but should not be tagged ref=A11. I'm not at all convinced that OSM should be making decisions as to what roads should be considered part of the A11 despite not *really* being part of it. However, if you want to do that, isn't this what the route= tag is for? ref= tags a physical entity, route= tags a logical route. - 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
Re: [OSM-talk] Relations not always brilliant
On Mon, 7 Apr 2008, Robert (Jamie) Munro wrote: It's not subjective, it is officially signed - the signs say A14 (A11). This happens all over the place in the UK A roads network. Don't road numbers in brackets generally mean leads to rather than part of? I can't see how you can argue that it is wrong to connect all the ways forming a large numbered road with a relationship, which seems to be what Richard is arguing. It seems to me that it is exactly what relationships are for. I'm not sure anyone is saying it is wrong, merely unnecessary and prone to causing confusion/errors. The fact that there is some disagreement here about _what_ should be part of a relation shows that this stuff isn't really clear cut. - 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
Re: [OSM-talk] English version of OSM foldout flyer
On Fri, 4 Apr 2008, Frederik Ramm wrote: Great to see that the work is being put to other uses! (Meanwhile I had to order a second print run of the German flyer as the first 5,000 copies are already gone!) Has anyone handed these out to random members of the public yet? I'm interested in what their response was? - 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
Re: [OSM-talk] Old names
On Thu, 3 Apr 2008, David Janda wrote: It appears to me that the name_old tag is meant for one name. But what to do if there are several? I am against the idea of name_old1 name_old2 and so on as these names I am refering to are in many cases so old that the order is not known. The recommended way of handling multiple values in a tag is usually to separate them with ; i.e. name_old=Foo;Bar;Baz - 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
Re: [OSM-talk] Lighthouses
On Wed, 2 Apr 2008, OJ W wrote: Tagging notes/discussion is at: http://wiki.openstreetmap.org/index.php/Talk:Tag:man_made%3Dlighthouse If anyone has comments on the tags etc, then please do join the discussion I've put together a bare-bones proposal for tagging buoys: http://wiki.openstreetmap.org/index.php/Proposed_features/Buoy I'd appreciate input, comments, etc. - 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
Re: [OSM-talk] Lighthouses
On Thu, 3 Apr 2008, Steven te Brinke wrote: Besides that, IMO starboard and port are not a good way to specify the type of a buoy. That is because in the Netherlands buoys are placed in the downstream direction, with green at the port side. However, at sea they are placed towards land, with green at the starboard side. So in fact you don't see the difference, only the definition is different. That's why starboard and port are not well defined. I think putting the lateral buoys in a relation would be a good plan - this means that to find the channel you don't need to know whether they are placed in the upstream or downstream direction, you just know that the bit between a port and starboard buoy within the same relation is the channel. i.e. imagine a pair of channels marked like: S P SP S P SP S P SP (where S is a starboard marker, P is a port marker). Without knowing the reference direction, it is a bit ambiguous - you could have 2 channels with the harbour to the South (so the port marker is on the port side when you're heading South). Or you could have 1 central channel with the harbour to the North and the markers on the edges could be part of other channels. If we surround them with relations it becomes more obvious: [SP][SP] [Relation 1][Relation 2] Now, to work out where the channel is, we don't need to know what the reference direction is, all we care about is that we can tell the difference between the port and starboard markers - the bit between 2 different markers in the same relation is the channel. In the above case, we clearly have 2 channels. However, tagging them port/starboard is still important since it lets us choose which symbol to render on the map (which must match what the physical buoy actually looks like) - 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
Re: [OSM-talk] Dry-weather roads
On Wed, 2 Apr 2008, Iván Sánchez Ortega wrote: I think some variation on the access tag make more sense, if only 'access=dry_season'. Good idea. Afterall the road/route is always there (ie. not intermittent), it is just not passable with normal vechiles. The *water* on the road *is* intermittent, however. Both tags are probably a good idea - the access tag tells you you can't access it some of the time, the water tag tells you _why_ you can't access it. I'm not entirely convinced about water=intermittent for tidal stuff though since tides are quite predictable so there could be much more useful information about when the water is present (e.g. under water when tide is 4m above chart datum). To some extent this is true of seasonal stuff too - you could have a tag specifying when the wet season usually occurs. - 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
Re: [OSM-talk] Dry-weather roads
On Wed, 2 Apr 2008, Iván Sánchez Ortega wrote: water=tidal and water=seasonal, then?? Sounds good to me, possibly with an optional qualifier tag such as: water:tidal:height=4(flooded by tides 4m above datum) water:seasonal:dates=09/01-03/31(flooded September 1 - March 31) - 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
Re: [OSM-talk] [tagging] RFC: railway=incline
On Sun, 30 Mar 2008, Cartinus wrote: Almost nobody would accept it if we suddenly had to use railway:name=, highway:name=, etc. on all ways just because there are some places where people want to tag the street and the the tramway on the same way object. What you'd need is a solution that works for all tags, not a few tags with namespace parts and all the rest without. Maybe the editors just need a new way of presenting the namespacing. This is basically no more than a tree architecture and makes a lot of sense to me. e.g. (using semi-fictional tags): . |-- highway | |-- type = residential | |-- name = Foo Street | `-- ref = B1234 |-- cycleway | `-- ref = 5 `-- railway |-- type = tram `-- ref = 78 I think that namespacing only raises the barrier to entry if it is inconsistent and isn't presented by the editors in a good way. - 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
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: and you can also limit the length of these GPS connection lines (draw.rawgps.max-line-length=x, in metres), for those cases where you get crazy zig-zagging. I had noticed a while ago that JOSM appeared to handle GPX files incorrectly (and presumably the same goes for GPX data retrieved from the OSM server) - Not sure if it has been fixed (I'm using a relatively old JOSM at the moment): The GPX files consist of trk elements (tracks), with each track containing one or more trkseg element (track segment). JOSM seemed to be joining the end of a trkseg to the start of the next trkseg rather than leaving them unconnected. The trk elements themselves are handled correctly though - they are left unconnected. This might be the cause of a lot of the crazy zig-zagging (which actually makes the GPS data completely unusable in some locations - Nottingham, for example, is totally obscured by the zig-zagging lines if you ask JOSM to retrieve the GPS data from the server.) Which brings me to another point - why not run a sanitiser across the database to try and remove obviously broken GPS data. For example, if the distance between two GPS points exceeds several hundred metres they probably shouldn't be considered part of the same track segment so this could be fixed in the database itself. - 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
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: I'll investigate that. However with data retrieved from the server, you don't even get the trkseg structure, you just get a ton of individual points and have no chance of finding out whether they belong to the same segment or not! Ouch - I hadn't realised that. :) The problem I saw was for local GPX files - I was generating them from GPS data stored in a database and had originally used a single trk containing many trkseg elements. JOSM rendered them with every point joined to the next, even if those points were in separate trkseg elements. I modified my GPX generator so that it used many trk elements, each with a single trkseg and JOSM rendered that correctly. When I saw a similar problem with the data downloaded from the server, I assumed it was probably the same problem, but didn't investigate further. Anyway, I'll grab the latest JOSM and hopefully it'll make some areas a lot more readable without all those crazy tracks - good stuff. :) - 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
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: * It is now possible to have arrows on the lines connecting GPS points (draw.rawgps.direction=true), I'm seeing a couple of slightly odd things with the GPS direction arrows: (screenshot) http://www.nexusuk.org/~steve/josm-gpsarrows.png They are pointing the wrong way - the blue motorway loop in the screen shot is traversed in the anticlockwise direction, but the arrows on the GPS track are showing it to be clockwise (seems to be the case for all the GPS tracks, so this isn't just an odd data set). Also, I seem to be getting a few extraneous arrows which always point East (visible on the right hand side of the motorway loop. - 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
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Yes, seems to be the case :) This happens when lines of length 0 are drawn. I suspect that those tracks that suffer from the east arrows have been uploaded twice, so that every point in them occurs twice, but I'll check that again. Maybe JOSM should be instructed to omit these arrows. Ah, ok - that makes sense. - 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
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Steve Hill wrote: Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Yes, seems to be the case :) To complicate things more, the direction arrows on data imported from a local GPX file are the right way around, so this problem is only affecting data being retrieved from the OSM server. - 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
Re: [OSM-talk] re contours
On Thu, 20 Mar 2008, elvin ibbotson wrote: Treating contours as shape files seems to me to be heavy on storage, downloads and processing. I have made a proposal in the wiki at http://wiki.openstreetmap.org/index.php/Relief_maps#a_proposal to use relief shading as a background to mapnik tiles. I'm sure there must be good reasons not to do this and look forward to hearing them. I hadn't come across that proposal before, but my initial thoughts are: Coloured relief as described is good for an at-a-glance idea of the terrain, but (IMHO) are less useful when you want to look at the map in more detail. It could be sensible to use this system on the low-zoom tiles and the switch to contour lines on the more detailed high-zoom ones. The proposed doubling of the intervals leaves them far too widely spaced at high altitudes which would render it more or less useless in mountainous terrain. For example, a ski resort may have the town centre at 1100m and the top of the mountain at 3300m - on that map the only colours you will see are the 1024-2048m and 2048-4096m bands - 2 bands to cover up to 3000m of altitude difference is nowhere near enough to be useful. On the whole I'm not convinced about reducing the band frequency with altitude anyway - if you're cycling (for example) at an altitude of 600m, a 100m high hill is just as significant to you as it would be if you were cycling at sea level, but in the former case it wouldn't show up on the map at all whilst in the latter it would be very obvious. With some modification to the banding intervals, it could be useful to use colours *as well* as contour lines on the map to make it easier to see which direction the gradient is (i.e. so you can tell the difference between a ridge and a valley without looking at the legend printed on the contour lines). - 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
Re: [OSM-talk] Contours server (was: Re: ski pistes)
Just a quick follow-up with some numbers for disk space usage for those interested. I had a go at importing 10 metre contour lines for the whole of Eurasia into PostGIS - latitudes of 0 - 46 degrees North required about 110 gig of disk space for the Postgres table and amounted to around 105 million contour lines. (I stopped it at this point before I ran out of space :) - the SRTM3 data set extends up to 60 degrees North). 0-46N across Eurasia amounts to 3244 1x1 degree tiles. So this averages you around 35MB of disk space to import a 1x1 degree tile into PostGIS (obviously dependent on the terrain the tile covers), giving rough estimated numbers of: * Africa: 111 GB (3250 tiles) * Australia: 36 GB (1060 tiles) * Eurasia:202 GB (5902 tiles) * Islands:5 GB(141 tiles) * N America: 82 GB (2412 tiles) * S America: 62 GB (1807 tiles) * WHOLE WORLD:498 GB (14572 tiles) So with half a terabyte of disk you can import the whole lot... There is also the higher resolution SRTM1 data set covering North America - I'm not clear on how using those data would affect these numbers - probably not much since you'll probably have roughly the same number of contour lines, they will just be positioned more accurately. - 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
Re: [OSM-talk] Contours server
On Tue, 18 Mar 2008, Martijn van Oosterhout wrote: I looked at the code the other day and it seemed rather inefficient. Fixing it will be a PITA though... Would be very nice though, I'm think of looking into it when I have time... I was pondering rewriting it from scratch with the aim to allow imports of the diff datasets from the start. It shouldn't be too hard (making it efficient is probably the hardest bit, but becomes less important if you're importing diffs most of the time rather than the whole planet). However, it will have to wait until I have time. :-/ - 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
[OSM-talk] Contours server (was: Re: ski pistes)
Contours layer presented by openpistemap is simply great. Does it exist a server publishing only this layer? I'm not sure how that would work - you really need the contours data set to be the bottom layer, with the normal layers on top of that (is it possible to ask OpenLayers to render the OSM Mapnik tiles on top of another layer? I suspect not since the tiles aren't transparent...) OpenPisteMap only has contours data for specific areas because the data set is pretty enormous (I did try converting the whole SRTM3 data set to shapefiles - I gave up by the time it had done about 3/4 of Eurasia and sucked up over 100 gig of disk space. I haven't tried pulling the whole data set into PostGIS yet - I wonder if that is any more efficient). Another consideration is that the contours tiles have to be tailored to the map type a bit - for example, the cycle map renders the contours closer together (i.e. it introduces each set of contour lines at lower zoom levels than the piste map). The mountainous terrain of the pistes results in unreadably close contour lines if you just try to apply the cycle map styles. I'm working on Viking, a desktop GPS data editor capable of rendering data on top of image downloaded on line. Having a contours layer would be usefull to prepare hicking. For that kind of application, it might be better to implement an API to retrieve the contour shapes from an online database and render them on-the-fly in the application. That would allow the user to tune the settings to suit the terrain. - 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
Re: [OSM-talk] Contours server (was: Re: ski pistes)
On Mon, 17 Mar 2008, Dave Stubbs wrote: There's also the amount of time it would take to render the tiles. It takes over 15 hours to render the contours used on the cycle map, and all things considered that covers a very small % of the planet surface at any kind of decent zoom level. It's a slow enough process that render on demand doesn't work so well either. So any such server would need a few TB of disk space or be a come back in 24 hours after request job, or both. I've been quite successful with doing render on demand - tiles which have never been rendered are pushed into a render queue and the HTTP connection is left idling. If the tile is rendered within 30 seconds the user gets it sent over the HTTP connection as soon as possible, otherwise they get a 404 and the tile remains in the queue until it is rendered. The render-server process is currently set to be able to render up to 4 tiles in parallel and also copes well with requests for tiles that are already queued or being rendered. That said, it is running on a pretty meaty server (an 8 core 1.86GHz Xeon E5320), and it isn't very busy (serving 15k - 36k tiles per day over the past 5 days). I suspect that storing the contours in PostGIS helps quite a bit too. My main performance issues revolve around importing the planet OSM file (osm2pgsql uses up crazy amounts of RAM (or rather, swap, in my case) - there is the -s option, but that is currently broken...). What I'm really after is a way to import the daily diffs into the existing PostGIS DB. - 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
Re: [OSM-talk] Contours server
Dave Stubbs wrote: it's faster to just let it use swap, I I/O load hits my server pretty hard. Trying to do anything else while that's happening is quite painful. :-/ Doing it without the heavy I/O load is preferable, even if it takes a couple of days - it can just trundle away in the background. Personally I now have 8GB RAM so don't care so much as long as the memory requirements stay below 4GB (it's only on a 32bit OS). Physically I have enough memory, but it is allocated to other virtual machines. One option might be for me to juggle the memory allocations between the VMs when doing an import. -- - 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
