Today in the mail I got yet another real estate mailer, trying to get me to sell my house in this fantastic market. Just before tossing it in the recycling bin, I did a double-take. The map they used to show the location of a recent sale included my neighborhood, and it was the OpenStreetMap.org Standard (Mapnik) rendering! These are produced by SmartZip, a company which does targeted marketing, directing recipients to SmartHomePrice.com which then directs them to the real estate agent which paid for the listing. So presumably thousands of others are receiving similar mailers.

Three things:

• There is no attribution
• The data is quite old (at least a year)
• Very cool!

(full size photo can be seen here on imgur.com

Lately I've been working on merging my county's park data into OSM using JOSM (this is more technically known as conflation). I've also been modifying JOSM and some plugins to try and improve the efficiency with which I do this, considering the county has 22,500 acres of parkland in 416 parks, not counting the parks which the county does not operate, but for which the county still has boundary data. I thought I'd share my process so far, in hopes that others with similar tasks might find some useful tips, and perhaps learn how others accomplish similar tasks or how I might be able to improve my process. Be sure to at least have the utilsplugin2 plugin installed.

First of all, I converted the government-provided (and appropriately licensed) Shapefile to an OSM.XML file using ogr2osm and a simple translation script to set the name, operator, and leisure=park tags.

1. Create new layer (blank)
   
2. Open government OSM file
   
3. Select and zoom to a feature to merge (click and press 3)
   
4. Merge feature to OSM layer (Ctrl+Shift+M) and delete (D) from government layer
   
5. Switch to OSM layer (Shift+A, then 1)
   
6. Download corresponding area from OSM database (Ctrl+Shift+D)
   
7. The next step will vary:
   
   
   • If the feature doesn't exist in OSM yet, then you're done
     
   • If the government feature is of higher spatial accuracy, select the two features and run Replace Geometry (Ctrl+Alt+G), resolving any tag/membership conflicts
     
   • If the government feature doesn't have better spatial accuracy, but has better tags, copy and paste them (Ctrl+C on the government feature then Ctrl+Shift+V on the OSM feature), then delete the government feature
   
   
8. Switch back to the government layer (Shift+A, then 2)
   
9. Repeat with next feature, go to step 3
   

Note that the Replace Geometry action can "upgrade" a node to a way or to a relation, or replace a way with a way. It can't yet "upgrade" a way to a relation or replace a relation with a relation, but those are on my TODO list.

… See full entry

For anyone who's used JOSM for a significant amount of time, it's likely they've been using utilsplugin2, which provides several useful functions. One of these is Replace Geometry, which replaces an existing but poor quality way with a freshly drawn one, preserving history in the process by transferring existing nodes to the new way. The usefulness of this function has somewhat lessened thanks to the ImproveWayAccuracy plugin, but I still find myself using it often.

I've recently enhanced this command to support replacing a node with a way (see this ticket for details). This is very useful and timesaving in a number of cases. One is if you come across features that are represented by both a node and a way (a violation of the one feature one object rule). Another is if you wish to upgrade a feature that exists as a node, such as by drawing the building outline of a restaurant. In either case, simply select the node and way, then run the command, which will transfer tags from the node to the way, and either delete or move the node, whichever allows keeping the most history.

Before, but especially after adding this functionality, I've seen the need to prompt the user to resolve tag conflicts like the Merge nodes tool rather than just blindly copying the tags. Please read this ticket and comment if you think this is a good idea. Also, I've seen some other situations which might lead to information loss or corrupt data. Please read and comment on this ticket.

If you'd like to try this new functionality, just update your plugins in the preferences dialog!

I've been hacking recently on JOSM and a few of its plugins, but the changes aren't quite worthy of an entry in the news page of JOSM.

Delete multiple tags at once

The lack of this functionality was bothering me for a while, especially while editing TIGER data and removing all the superfluous tags. It's pretty intuitive, just use Ctrl+A to select all tags, or use Shift and Ctrl to select a subset, then press or click Delete. For some reason Home and End don't work, they must be caught by some other component. This functionality is in JOSM 4773 and above. (ticket)

Delete nodes with ImproveWayAccuracy

Sometimes roads are way over-noded and have bad alignment, so you can use this plugin (IWA) to fix the alignment, but then there's often a few nodes which you don't want to keep. It's tedious to switch into select mode, delete the node(s), then back to IWA. Note you cannot delete nodes with tags or that belong to other ways or relations. ToeBee did most of the work on this one, but I added in the preview drawing, added some mode hints, committed the patch, and updated the wiki. (ticket, wiki)

JOSM plugins can provide search operators

This one's working, but isn't cleaned up enough to commit quite yet. The patch to JOSM allows plugins to register new search operators. To demonstrate this I modified utilsplugin2 to provide inside, intersecting, and allintersecting. This allows searches like leisure=pitch inside amenity=school to find all sport pitches inside school grounds. Once the API is finalized and committed I'll add other operators like adjacent. (ticket)

If there's anything you've found missing in JOSM or the plugins, and you know a bit of Java, why not try fixing the problem yourself! It can be quite fun.

I've thought about making a plugin for JOSM to unabbreviate street suffixes, and put my thoughts down on a wiki page, and mentioned it on the dev@ and josm-dev@ lists, but thought I'd mention it here since I'm asking more for design input rather than development advice (but I'll take that as well!).

Read (and edit!) the original wiki page here:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TextTransform

---

These are some notes about the creation of a JOSM plugin which can perform text transformations on tags. A possible name is TextTransformer or TagTransformer.

Use cases

Un-abbreviating

The motivating idea for this plugin is to un-abbreviate street types, such as "St" -> "Street", "Rd" -> "Road". As abbreviations vary from region to region, there needs to be a way to choose between different abbreviation dictionaries and logic (street type at beginning, at end, etc.). By default (or by design) this should not apply to objects that have tiger:reviewed=no.

… See full entry

The TIGER wiki page has been woefully out-of-date for quite a while now, so I've gone through and cleaned it up as best I could (I still haven't gotten a definitive answer as to whether 2005 or 2006 data was imported back in 2007/2008 by Dave Hansen).

I and a few others are interested in creating tools for visualizing differences, finding missing streets as well as mis-spelled street names with OSM and the latest release of TIGER, 2010. TIGER 2010 is much improved from TIGER 2005 (or 2006), so it is at least useful for comparison, similar to the Ordnance Survey Locator data for the Uk.

I'm also interested in defining a good attribute mapping from the new MTFCC's used by TIGER 2010 so that we can create OSM.XML files that experienced contributors can use with JOSM to perform selective merging (a hairy process, and not for beginners!). I've created a rough start for mapping the road attributes, however I have only used the formal documentation and haven't yet compared these with how they're actually used, so take them as a work in progress.

Please take a look at these pages if you're interested, and consider providing feedback either on the wiki or the talk-us mailing list.

I've been using the new ImproveWayAccuracy plugin in JOSM for a week or so, and I've gotta say it's one of the best plugins! It makes fixing road alignment so much easier and faster. Thanks go to the author, Alexander Kachkaev!

Like I've mentioned in a previous entry, I wrote an article for a local newsletter that's distributed to around 7,000 homes and businesses. It's now actually in print! Of course I now see some things I'd do differently, but no changing that now. For the curious you can read the article on page 13 of the May issue, titled "Mapping Burke Centre":
http://burkecentre.org/updated%20folders/CONSERVATOR/May-final8-14.pdf

I've mentioned this on the mailing lists, but thought I'd bring it up here. I've been thinking more and more about a tool to conflate (match/merge/sync) nodes in OSM data with external data (or even itself), and how useful it would be. For my particular interests it would be useful for merging bus stop and interstate exit data I've recently obtained, as well merging the latest GNIS records. It could even be used to merge address data on nodes with building polygons.

I've sketched out a possible work flow for such a tool, a possible algorithm, and took some notes on a possible JOSM plugin, including a mockup of a configuration dialog. I would appreciate any input or assistance.

http://wiki.openstreetmap.org/wiki/Conflation/Nodes

I'm putting together an article for my local community newsletter, published by my HOA, to promote OpenStreetMap. It's received by around 7000 homes and businesses, which isn't huge but is a start. I needed too keep it under 500 words, which I found difficult. If you have any comments on my rough draft please let me know!

Mapping Burke Centre

As some of you are aware, Burke Centre has a trail map that was created several years ago with the help of Robert Pew from RestonPaths.com and Oaks Trustee Luanne Smith. It is a good basic map that is available in print at the Conservancy office and online as a PDF. However there are several shortcomings, chief among them is the lack of an interactive online map and a finer level of detail. Have you ever wanted to know the fastest way to walk to the library using the trails, or to be able to search for all tot lots with swings, or to see exactly where cluster boundaries are located? These and other questions can be answered thanks to a project called OpenStreetMap.

OpenStreetMap (OSM) was started in 2004 to allow the creation of a free and open map of the world. You can think of OSM as Wikipedia for maps; anyone can go to OSM.org, view a location on the map, and then click “Edit” to begin correcting or enhancing the map. Those with GPS devices can upload tracks that they’ve recorded, and when combined with aerial imagery shown as a background, this allows the user to trace in new objects on the map.

… See full entry

I posted this on the MappingDC group, but thought I'd broadcast it here as well.

I'm considering arranging a meetup around George Mason University or
Fairfax City in the coming months, and was curious if anyone would be interested. I've had contact with one person who is definitely interested.

I'm working to get my community involved in OSM, as I'd love to not be the only mapper in my neck of the woods, however I also don't want anyone else to touch the map because I know they won't map as well as me! Am I the only one that thinks this way? However I'm sure my fears are unfounded and my community and OSM will be better off for their involvement.

Just finished adding all 12 seasonal farmers' markets in Fairfax County and Herndon as suggested by the project of the month. These are seasonal, so I had to figure out how to create seasonal opening hours; hope I got it right!

I think there should be a method for tagging individual parking spaces rather than entire lots. At least one other individual has mentioned this on the wiki on the amenity=parking talk page.

Why would we want to do this? The obvious reason (at least to me) is to differentiate between general parking, handicap parking, mothers/parents/elderly parking, etc. However this can also be useful for parking lots which have reference numbers assigned to each space, such as shown in the associated map. There's nothing preventing people from mapping individual spaces now, the only problem is there is no way for data consumers (including renderers) to know that these individual spaces are related.

How to do this? Well I don't think we really need any new tags, just a new relation, and it should work no matter how a parking lot is mapped. If an individual space is mapped, it will have capacity=1, and maybe even capacity:disabled=1 if it's a handicap spot. If you have a whole row of spaces of the same type you can just draw them all with one closed way, and tag it with the appropriate capacity=*.

Then what we need is a relation to tie all these ways together to represent a logical parking lot. Perhaps there can be a role=label member node which designates where the P symbol and/or parking lot name should be drawn. This prevents renderers from drawing dozens or hundreds of P's. I'm not sure what type=* the relation should be, or what role=* the parking spaces (individual or group) should have. It's such a simple relation I almost feel like something out there should already work.

If you have any suggestions, please comment, and I'll try and turn this into a proposal.

As my first diary entry, I'm not sure what I should write about. I first fiddled with OSM several years ago, but haven't seriously gotten involved until recently. I'm at the point right now where I'm interested in so many facets of OSM, I don't know where to spend my time.

One definite goal of mine is to create a comprehensive map of Burke Centre, population 17,326, located in Fairfax County, Virginia. I've recently been getting more involved in my community, including volunteering with the home owners association. We have a trail map, but it is simply a low resolution raster map created years ago, with little detail and of course all the other benefits OSM offers. I've been experimenting in my neighborhood, and I'll probably post on this specifically in the future.

I'm also very interested in micromapping, that is mapping small features which most don't spend the time to care about. As part of mapping Burke Centre I'm experimenting with mapping every house (including their entrances), sidewalks, driveways, waste baskets, benches, and more. I've found that current tagging schemes often don't work well with micromapping, and renderers thus tend to produce overcrowded layouts, not to mention completely ignoring some of the less frequently used features. Again, I'm sure I'll have more to say about this in the future, but I have created a micromapping stub on the wiki.

I've found JOSM is the best tool for editing OSM, and I have been fiddling with the code as I go along. One thing I've done is patched the PDF Import plugin to support setting projection preferences, though it seems few people even use that plugin, perhaps because the documentation is lacking. To support my work in Fairfax County, I also created a new JOSM plugin which uses the Proj4J library to provide a large number of projections. It works well for my purpose of using the PDF Import plugin to use Fairfax County cadastral maps, however it certainly needs additional testing.

… See full entry