OpenStreetMap

asciiphil has commented on the following diary entries

Post When Comment
Low quality traces almost 2 years ago

Or the data is out of date and the interchange has been reworked; I've seen both. But it's also likely that someone entered the data before there was good aerial imagery of the spot and was going from memory and estimates, which is not horrible, since it's right enough to be better than no data (even if the topology is a little off).

On Tracing from Poor Imagery over 2 years ago

Relations take priority. If there's no relation or it doesn't understand the relation, the way's ref= tag just gets rendered in a lozenge.

The shields are from the same code that I linked from talk-us@ in April. I don't have the disk space or bandwidth to host general access to my TopOSM rendering, but the proof-of-concept shield rendering is still at http://elrond.aperiodic.net/shields/ . I still need to get around to documenting the tagging it understands, but most of the details are in these talk-us@ posts: http://lists.openstreetmap.org/pipermail/talk-us/2012-April/007735.html http://lists.openstreetmap.org/pipermail/talk-us/2012-April/007752.html http://lists.openstreetmap.org/pipermail/talk-us/2012-April/007781.html

On Tracing from Poor Imagery over 2 years ago

Paul: It's TopOSM with some of my own modifications, most notably the addition of the highway shields from osm-shields.

stevage, Sanderd17: Those are good points, and I wouldn't argue that imperfect imagery means you shouldn't add things. I think people should consider how their imagery might be wrong, which is more of an issue when it's old and has things that don't exist anymore, but I thought this was a nice illustration of one incorrectness that aerial imagery can exhibit.

Also, I came across this while doing a general cleanup on I-68 that included adding surveyed speed limits, aligning ways to imagery, making sure all the road's bridges and lane counts were represented accurately, and making sure all the interchanges were topologically and geometrically correct (among other fixes, I found a few motorway_links that were pointing the wrong direction).

Untangeling ways over 2 years ago

I've dealt a lot with shared nodes in a variety of situations, both created by me and others. I'm not enamored of the practice of sharing nodes between roads and areas, but I prefer if adjacent area features share nodes. That reflects the reality that they abut each other and makes adjustments (if the river shifts course, or just if you're improving the accuracy of the ways) easier.

One of the two alternatives is using adjacent nodes, which makes adjustments a pain, can make targetting the right node problematic if they're really close, and doesn't reflect the situation on the ground.

The other alternative is building multipolygons out of shared ways. I used to do area features this way, but found that the tools we have don't always deal well with this, and (subjectively speaking) they seemed to be broken by other mappers more often. These days, I try to make area features with continuous, closed outer ways, even if I need to use a multipolygon to add inner ways. When I need multiple outer ways (because there are more than 2000 nodes along the perimeter, usually), I try to break it into pieces in such a way that the line between the endpoints of each piece remains entirely in the interior of the feature, although it's not always possible to do that.

Large amount of coastline added by user who has not agreed to the new license - what to do? over 2 years ago

The odbl=clean tag is probably not the way to go for this. That tag means, roughly, "There are people in the edit history of this object who have not agreed to the new license, but I'm saying that its current state is not at all derived from those people's contributions." For the coastline, all of its nodes' positions are from people who haven't agreed to the new license, and the only way to get it compatible would be to retrace the entire thing. And, as mentioned above, people are looking at ways to replace this tainted data all long the West Coast of the US.

Also, it won't be horrible if some coastline data is removed during the license changeover. Most renderings don't use that data directly: they use shapefiles derived from the data, so we can continue to use the old shapefiles until the coastlines are ready to generate new ones. The missing data will still have to dealt with, but we have more time to do it than it might at first appear.

Little River Rail Trail almost 3 years ago

I tag rail trails as highway=path (or highway=cycleway or highway=footway, depending on the trail) and railway=abandoned. Also, following some tagging I've seen NE2 do, I also add an old_railway_operator= tag when I know what company owned the railway when it was last in operation.

contourlines-shape-format almost 3 years ago

There's a page on the wiki, https://wiki.openstreetmap.org/wiki/Contours , that discusses how to make your own shapefiles. The short version is: get a files with elevation data in them, then run gdal_contour to generate contour shapefiles from the raster images. If you don't have a better source for elevation data, SRTM (linked by Sanderd17 above) has near-worldwide coverage at an acceptable resolution. (If you're in the US, the National Elevation Database is much better quality.)

Calling Australians over 3 years ago

The email you link to says the exact opposite of your small text--NearMap-derived OSM contributions made before June 17th will *not* be removed from the ODbL OSM data (assuming you have also agreed to the ODbL+CTs).

A Brief Dalliance with Imports over 3 years ago

I plan on updating the wiki, once I've got my tileset available for general use. (I'm currently working with my hosting company to see what parts of the rendering chain they're willing to install and which ones I need to set up and maintain myself.)

Getting Accept / Decline licence screen on logon today *PART2* over 3 years ago

Personally, I'm not too concerned about this.

First off, OSM data can be used (and is being used right now) to fill the coffers of commercial organizations. If you disagree with that, I can't argue with it, but there's no difference there between the current state of affairs and a hypothetical dissolution of OSMF.

Now, it could happen that someone could buy the OSM database in bankruptcy proceedings and then close the dataset: cease publishing planet.osm files and make changes to the data that would never be published. But we would still have the last dataset from before the sale, and the license terms (CC-BY-SA, ODbL, or whatever) would still apply to that data. Nothing would be lost except the future usefulness of the data (assuming no one else forked it and kept going, and I think in those circumstances, someone would do so).

I suppose the worst case would be if someone bought the OSM data rights and tried to keep the community contributions coming in but under a more restrictive data license (like Google's, say). That would probably fall under the view that your contributions were helping to perpetuate an environment of more closed data. My personal comfort when considering such a possibility is that I think large portions of the community, particularly the heaviest contributors, would abandon such a project, leaving it effectively the same as the data dead-end I described above--the new owner gets to use the data, the same as any company can now; we still have the last unencumbered data release; we all lose a future of updates to the data unless someone makes a fork.

If you don't want to contribute further to the project, I can understand that, but the prospect of losing data (which we would if you reject the new CTs) in what I see as a vibrant open data project makes me sad.

Minutiae about Tile Rendering Queues over 3 years ago

"Leave this setup running for a week" was a premature statement, apparently. I got my first really big tile expiration and it wiped out all the rendering I'd done for the past few days.

The rendering process spends most of its time extracting tiles from the metatiles, so I've implemented my old approach of only extracting the changed tiles within my new AMQP setup. The render queues now just get messages of the form 'z/x/y', while the database expiry table has the following fields: zoom, metax, metay, layer, x, y, expired. The expiration process only sends a render message if there are no pending tiles for a metatile, but it will expire individual tiles as it sees them. When a render process gets a render message, it pulls all that metatile's expired tiles from the database, renders the metatile, and then only extracts the changed tiles.

This should put me back into the place I was with my previous setup, where I was able to render all the changed tiles from zoom 11 and up slightly faster than they expired. It'll take a while to get through the backlog of metatiles I already had queued, but the problem shouldn't be getting worse while I'm doing it.

Great Tool For Clean-up over 3 years ago

I believe one of the wiki pages points out that the original intent of the TIGER data was to be printed out on clipboards and referred to by census workers walking around neighborhoods. Sub-meter (or even sub-decameter) accuracy wasn't as important as getting the general geometries of the roads relative to each other.

in recent years, the Census Bureau has put more work into getting greater accuracy in their road data, but reimporting their new data into OSM is pretty much a practical impossibiity.

Custom Buttons in JOSM almost 4 years ago

You can write an XML file to add your own presets, which you can then put on the button bar. See http://josm.openstreetmap.de/wiki/TaggingPresets .

I use the USGS's high resolution orthophotography for alignment a lot, so I added a button that just sets the tag "source=USGS Ortho".

Generating a Planet PBF almost 4 years ago

Might I suggest using BitTorrent to distribute them? I'm pleased so far with the torrents over at http://osm-torrent.torres.voyager.hr/ .

mapping house numbers almost 4 years ago

I do house numbers as part of my process for mapping neighborhoods. My workflow is to make sure the roads are aligned to aerial imagery, possibly drawing houses, too, print the area via walking papers, and then visit and make notes about what's where. I usually just write down the first and last house number on each side of the street, but I try to make other notes if numbers are skipped.

Whether I map each individual address or just an interpolation way depends on how many addresses there are.

Problem with Yahoo WMS plugin in JOSM almost 4 years ago

You can also right click on the imagery layer in the "Layers" box and select "Change resolution" to have the WMS plugin reload that imagery at the current zoom level.

First Indian (I guess :)) about 4 years ago

There are at least a few others. pavi is pretty active.

India is, of course, a big place so the more mappers the better. Welcome to OSM!

Rendering Route Shields from Route Relations in Mapnik about 4 years ago

Okay, sample rendering added (currently without the lowest, elevation-based layers or the highest layer, which would have town names).

Rendering Route Shields from Route Relations in Mapnik about 4 years ago

I'll see about a screenshot. My current rendering setup is based off of TopOSM, which renders things into a lot of separate layers, which in turn makes one-off renderings more difficult. (Plus I'm doing the base layer differently and I probably have another four to five days of processing before it's ready to be integrated with the other layers.)

As for SVGs, I didn't think of that, since it's a relatively new development. I don't think it would buy me much; just not having to render the SVGs in the Gimp.

SRTM and NED elevation data over 4 years ago

I'm more or less doing hypsometric coloring, too. The lowest layer of my rendering is a relief-colored image based on the same data as the hillshading. The colors I'm using are pretty subtle, though. See my previous diary entry for some examples of the different colors that can show up.

Basically, since I'm doing very gradual color changes, there's practically no difference between NED and SRTM colors for my current rendering.