Re: [OSM-talk] Landuse areas etc. abutting highways
Mike Harris wrote: Thanks to those who responded to this thread. Advice gratefully received. There seems to be a clear majority preference for option (b) - the more detailed approach that avoids superimposing boundaries of areas (and their nodes) on an adjacent way (and its nodes). I fully understand the two caveats: 1. It is only worth being precise if there is precise data available. 2. There are a few exceptions where, for example, the character of the adjacent area has access features more like that of a normal linear way - the pedestrian area is a good example. I am persuaded that the advantages of forward compatibility and a higher standard of mapping justify my small efforts (where I have good GPS data) in separating out superimposed areas/ways and using option (b). I am particularly pleased to receive support for splitting single large landuse areas (e.g. =residential or =farm) that cross large numbers of ways. Let me encourage you to use option a), based on the reasoning of Frederik Ramm. In detailed mapping, everything is an area way which share nodes with its adjacent areas. When roads etc. are linear features, it means they have *indeterminate* width and the only non-arbitrary representation of this in an editor is for the width to be zero, with adjacent areas on both sides sharing the nodes - option a). This makes it consistent with the detailed modelling approach. I would look at the linear road etc. as being, not a centre-line, but an indeterminately wide structure comprising the road surface, sidewalks, verges etc. up to a boundary (which in the British countryside would often be a hedge.) By mapping with option a) you are saying that the golf course, say, comes up to the road's boundary hedge but that you haven't specified exactly where that is. If you do know, you are into a detailed mapping approach. If a linear road is still used then it would now be interpreted as a centre-line, as is sometimes done with rivers. Since I map in the same are as you, I suspect that in most cases you do not have enough information to use the detailed mapping approach. Even with arial photography we have available, poor resolution and interference from tree cover and shadows often does not allow the separation between the hedges to be very reliable. Editor support for ways sharing nodes is certainly poor, but as with inadequate renderers, we should improve them rather than adding artificial data (arbitrarily positioned structures) into the database. Landuse areas which cross a large number of ways are very common. Surely you don't intend to divide say, Delamere Forest, into a large number of separated areas separated by the paths and tracks? When you do need to do it, separating an area into two at a road is certainly laborious and maybe somebody should build a JOSM plugin to do it. Chris -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: 05 October 2009 15:52 To: Marc Schütz Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] Landuse areas etc. abutting highways 2009/10/5 Marc Schütz schue...@gmx.net: 2009/10/5 Marc Schütz schue...@gmx.net: But a) could be used as acceptable temporary solution until someone with better information (like having aerial photography) remaps it as b) Yes, this is basically what I wanted to say. Leave it to the mappers whether they want to use a way or an area for a road. it will be much harder to add this detail, if all areas are merged though. Not really. JOSM supports disconnecting ways since a long time now. But anyway: doing things wrong just to make editing easier is not a good thing. +1. That's why adjacent landuses (see topic) shouldn't be extented to the center of the road. But with option (b) and a linear way you would have a gap next to the road. In the case of landuse, this is not a problem in practice, but if there is a place, there you need to insert artificial ways that are not there in reality, just to get the connectivity between the two objects: http://osm.org/go/0JUKytHID-- which objects are you referring to? parkings usually have those ways (for crossing the sidewalk) so they won't be artificial, and pedestrian areas are the exception I mentioned above. Look at the google sat image: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuths ll=37.0625,-95.677068sspn=59.856937,107.138672ie=UTF8hq=hnear=Bayr euth,+Bayern,+Deutschlandll=49.946316,11.577148spn=0.000754,0.001635 t=kz=20 That's the mentioned pedestrian area. I agree with you here. Mapping it the way it is done there does not really make sense: Either the exact geometry is important for you, then you should convert both the plaza and the road to areas. Or it isn't, but then there shouldn't be a problem with extending the plaza so that it borders to the road. +1. but that's still pedestrian areas / highway areas. In these
Re: [Talk-transit] pay_scale_area
Christoph Böhme wrote: In my opinion the name tag is used as a general purpose tag in OSM for names of all sorts of things. So, it appeared quite natural to use it for recording the names of the plus bus zones as well. From the other tags renderers can easily guess what type of object the name belongs to and the decide if it should be displayed. So there is no need to use namespaced versions of the name tag just to prevent the renderer from displaying it. It is rather useful that Mapnik will display a name of a feature which is of general interest but may have unknown tagging. For a new feature like PlusBus zones that are not intended for display on a general purpose map, it make more sense for them not to have a name or ref tag than to enter each one of them for non-display in the general Mapnik stylesheet. As a general rule, a new feature should not break existing code if possible. It is easily possible in this case by adding a prefix, with very little downside. Chris ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NAPTAN Import: Plus-bus Zones
Roger Slevin wrote: The PlusBus zone data comes from PlusBus – so please don’t try to change it. If you think it is wrong, then let me know and I will ask PlusBus to review the information. The Wrexham and Ruabon PlusBus zone has been imported without any reference to Wrexham (the more important location): name = Ruabon public_transport = pay_scale_area ref = RUABON source = naptan_import While this presumably corresponds to an entry in somebody's database, it causes a bit of FUD in OSM. Presumably I could edit the name tag, in spite of the admonition above. But name tags are rendered by Mapnik at high zooms (here as a disembodied name 16km from Ruabon). For these areas, it would be better to remove the name tag and use note instead, e.g. note = Wrexham and Ruabon PlusBus area. Chris ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-GB] Roundabout, ways and relationship policies
Jack Stringer wrote: Why do we cut them up for the bus routes? Wouldn't it be easier to build a navagation app at does the calculation using all the stops as waypoints. The resulting calculated route might not actually match the route the bus really takes. You might argue that it doesn't matter so long as the bus goes via all the stops, but IMHO it is wrong since there may be reasons for knowing the route the bus actually takes rather than just what stops it goes via. I understand that people would like to put bus routes into OSM but does it have to require the cutting up of roundabouts and junctions? I would not go around cutting stuff up just so I can put in a route of ice cream van. OSM's database can't hold all the information there is about everything. Among the many criteria for not including information are whether: - the data is ephemeral - it is better represented elsewhere - it distorts the OSM database Bus routes are on the edge of all of these. Where I live routes are changed frequently (sadly often by being removed). Route and timetable information would ideally presented together (some routes operate only once a week). There is likely to be a big increase in mash-up representations with OSM data as just one of the layers. Public transport information is ripe for innovative interactive presentation along these lines. I would prefer to wait the short time until this happens rather than distorting the OSM data unnecessarily. Chris ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Official database of 350, 00 GB bus stops etc and 50, 000 places to be made available!
Peter Miller wrote: The UK Department for Transport, together with Traveline, is offering to make available the bulk of the data from their NaPTAN and NPTG data sets to the OpenStreetMap project. Well done Peter Miller, this is very welcome and illustrates the importance of OSM having professional supporters with influence as well as vision. But it sounds as if the DfT is conceding the concept of open data is rather reluctantly: the transfer process seems to complicate things without any useful result. For the avoidance of doubt the datasets themselves will remain Crown copyright. The Department is however offering a single one-off bulk import to OpenStreetMap under the required CCBYSA licence used on OSM. ... An import process will be designed by the team and agreed with the contact person at the DfT ... On completion of the import the source datasets would be deleted. Couldn't somebody write a script to re-extract the data from planet? They would then have the NAPTAN and NPTG data, still with Crown Copyright but with a CCBYSA licence, which they could publish. The Department of Transport would no longer control of who has use of the complete dataset, which presumably is the reason for the complicated transfer process. It's a pity that the data wasn't released with fewer strings in the first place, but I guess this was as far as the DfT was prepared to progress. Chris ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Announcement: Second City, Birmingham, and its surrounds completed
Andy Robinson (blackadder-lists) wrote: It is with great pleasure, and not just a little excitement, that I can announce that the mappers in Birmingham having set the task of completing the whole of the city by Christmas have achieved just that. Well done, a triumph for effort and organisation. Wouldn't it be nice if there was the facility to show the completed area on the map, and watch it creep through the Black Country next year? Chris ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] OSM Mapnik not displaying
Jon Burgess wrote: On Thu, 2008-09-25 at 12:28 +0100, Chris Morley wrote: Can somebody help to find out what has gone wrong with my system? (Windows XP, ZoneAlarm Firewall). With Firefox 3 (which is generally working as expected) the Mapnik tiles at http://www.openstreetmap.org don't display - just the logo and ...more OSM coming soon (yuk). Osmarender, the Cyclemap, NoNames all display ok. With Internet Explorer and Firefox 2, Mapnik is ok, but it is not with some other programs, http://www.informationfreeway.org, http://geo.topf.org/comparison/index.html and http://sautter.com/map/. This behaviour may have started when I had to re-install Firefox 2 to get the Yahoo image background in JOSM. The firewall doesn't report blocking anything relevant, as far as I can see. Any suggestions? You say other applications work. This makes me think that maybe you accidentally added tile.openstreetmap.org to either adblock or blocked images from this domain. The display of images from tile.openstreetmap.org had indeed been turned off in Firefox (for no reason apparent to me). Thanks for the help. If all else fails, try creating a new profile. http://support.mozilla.com/en-US/kb/Managing+profiles The Mapnik layer definitely works fine in FF3. I use it all the time. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Mapnik not displaying
Can somebody help to find out what has gone wrong with my system? (Windows XP, ZoneAlarm Firewall). With Firefox 3 (which is generally working as expected) the Mapnik tiles at http://www.openstreetmap.org don't display - just the logo and ...more OSM coming soon (yuk). Osmarender, the Cyclemap, NoNames all display ok. With Internet Explorer and Firefox 2, Mapnik is ok, but it is not with some other programs, http://www.informationfreeway.org, http://geo.topf.org/comparison/index.html and http://sautter.com/map/. This behaviour may have started when I had to re-install Firefox 2 to get the Yahoo image background in JOSM. The firewall doesn't report blocking anything relevant, as far as I can see. Any suggestions? Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
Karl Newman wrote: On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann [EMAIL PROTECTED] Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme (http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Yes, and that method is not topological, which makes it very difficult to associate that feature (bus stop, house number, whatever) with the way that it's actually located on. It should either be a node that is part of the way, or have a relation to connect the node with the way. I think that the topological aspect of OSM's data structure is important and well worth maintaining in nodes and ways as well as in relations. We are not just drawing pictures, we are also recording relationships. This is why the representation of a mooring - a stretch of canal where boats tie up - as a separate way not connected to the canal seems wrong to me. In this case and with bus stops or house numbers, if you convey which side it is on by having a separate node or way displaced an arbitary short distance to one side, then you lose this side information at lower scales, when it may still be important to a user. With a topological description it is still available. Left/right are sometimes criticised as being dangerous because they can be accidentally reversed. It is editing programs that do all the reversing and it would be better if they provided better support. It would not be difficult to have a scheme with automatic reversal of tags (on the way or its nodes) containing left or right or a few others (like oneway), together with a more intelligent warning for the user in other cases. Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help providecompleteness tools
Andy Robinson (blackadder-lists) wrote: Verification is a whole new ballgame. I think throughout this discussion there is tendency to get hung up on the word complete, which has been used as a shorthand but is being interpreted differently. In everyday use it has an implication of perfection and that there is nothing more to be said. I think what we should be talking about is an area being filled in, without implying perfection or immutability. You should expect as high a proportion of mistakes in a filled-in area as in an incomplete one, but fewer omissions. However, if there is a blank space on the map, you can assume that it really is empty in a filled-in area, but you would not know if it was in an incomplete area. Measures of quality and guarantees of correctness require filled-inness, but I think should be regarded as more advanced concepts. I agree with Andy, we should walk before we run - start with an implemention of filled-inness - verification, etc. can come later. Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
David Earl wrote: Here is what I was going to do: 1. use a set of ways like coastline (i.e. with an on the right rule, because they'd be too long as one way), to define areas of completeness. By definition, coastline would form one boundary. 2. Render these plus coastline to a new set of tiles (possibly only at one zoom level, say 13 or 14) so that complete areas are transparent and incomplete areas are semi transparent red, say. Use the ocean tiles database to avoid putting red over all areas of sea. 3. Present these tiles as a layer. For other zooms either combine or divide, or sample, or simply rescale in the browser - the edges need only be quite coarse. I felt this leveraged most from the tools we already have so would be the most straightforward to implement. I was going to have only one measure of complete, that is the surveyor asserts that all publicly-accessible roads are present, with names for all except for those impossible to determine and when that is indicated, and all key points of interest from a limited set: schools, pubs, places of worship; and any railways and significant watercourses. I think it would be confusing for a consumer to have lots of variations in what complete means - just an indicator to say you can't really trust this area yet would be simple. However, since the boundaries can be tagged, there would not be any problem about expanding this for internal use to cover degrees of completeness. I think this is the right approach. I prefer the completeness boundary being a tagged way over the predefined squares approach suggested by Andy because: a) Being able to expand the boundary after each session is likely to be a great motivator. I suspect that this progressive taming of the wilderness or making order out of the void is what drives many mappers. b) Applicability to small or irregular areas (route to work?) might encourage more users. c) No additional tools or procedures are need by the mapper. Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. This covers the essential basic requirements for a number of potential applications for example, routing, delivery, estate agents, bus services. The points of interest, etc. are clearly desirable and but may not be always collected. For instance, tracing from arial photos and naming from an out of copyright gazeteer; or imports like TIGER. (Also I'm not sure I collected all of them when I started 2 years ago.) Start basic and have these in a subsequent level. Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] OSM needs a measure for completeness
David Earl wrote: I've said before and I'll say again: we need a way of asserting this area is complete (for one or more definitions of completeness). Andy Robinson (blackadder) wrote: The only way that we are going to individually or collectively state the completeness of a specific area is to carry out a verification process. It doesn't have to be done by third parties or even different contributors but it does need to be done by someone. We need a simple tag to display verification, perhaps the username and a date, say verification=blackadder_20080111 or similar. Martin Trautmann wrote: Is OSM that far that we need verification and quality ensurance? We are still far from completeness, which might be a primary goal. I have started a new thread with a measure for completeness in the title because this is an important topic for OSM. But the response to the recent posts quoted above, and my raising of it last July, has been only luke-warm. I wonder whether this is because completeness is associated in people's minds too closely with verification. As Andy has describes it in the (incomplete) quote above, verification involves individual accountability - I personally accept responsibility for the accuracy of this data. I don't think this is suitable for OSM at the moment; it may be necessary in the future if and when OSM becomes a serious alternative to commercial suppliers - but not yet. I, and probably others, are eager to make their contributions of as high quality as possible, but are wary about making a public and personal commitment to their accuracy. As is the case for all other mapping information, an assertion of completeness should only imply the best endeavours of the contributor, not a guarantee of 100% correctness. If you have ridden round a housing estate systematically and collected all the required information, you can reasonably say the area covered is complete. With this understanding, completeness would become part of routine mapping. It would encourage a systematic approach and the collection of any missed information. A possible detailed approach is as follows. A completeness boundary would be modelled on coastline: it would enclose an area, but would consist of many (ordinary) ways, with the completed area on the right. They would be tagged with one (or possibly more) definitions of completeness like major roads, public roads, public paths, which would be defined on a wiki page. Boundary ways would be moved or added on a day-to-day basis by anybody with local knowledge. An area might even have holes in it. Somebody would provide an overview map showing completed areas, and its animation would feature in most presentations on OSM. OSM really needs a measure for local completeness to demonstrate its progress externally. I hope enough people can be roused to discuss, and hopefully agree, the principles, before deciding on an implementation. Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
