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" : 2009/10/5 "Marc Schütz" : >> But a) could be used as acceptable temporary solution until >> someone with better information (like having aerial >> photography) >> remaps it as >> b) > Yes, this is basically what I wanted to say. Leave it to the > mappers whether they want to use a way or an area for a road. it will be much harder to add this detail, if all areas >> are merged though. >>> Not really. JOSM supports disconnecting ways since a long >> time now. But anyway: doing things wrong just to make editing >> easier is not a good thing. >> >> +1. That's why adjacent landuses (see topic) shouldn't be extented to >> the center of the road. >> > But with option (b) and a linear way you would have a >> gap next to > the road. In the case of landuse, this is not a problem in >> practice, but if there is a place, there you need to insert artificial ways that are not there in reality, just to get the connectivity >> between the two objects: > http://osm.org/go/0JUKytHID-- which objects are you referring to? parkings usually have >> those ways (for crossing the sidewalk) so they won't be artificial, and pedestrian areas are the exception I mentioned above. >>> Look at the google sat image: >>> >> http://maps.google.com/maps?f=q&source=s_q&hl=de&geocode=&q=bayreuth&s >> ll=37.0625,-95.677068&sspn=59.856937,107.138672&ie=UTF8&hq=&hnear=Bayr >> euth,+Bayern,+Deutschland&ll=49.946316,11.577148&spn=0.000754,0.001635 >>> &t=k&z=20 >> That's the mentioned pedestrian area. I agree with you here. >> >>> Mapping it the way it is done there does not really make >> sense: Either the exact geometry is important for you, then >> you should convert both the plaza and the road to areas. Or >> it isn't, b
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 provide"completeness" 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
