Showing posts with label OpenStreetMap. Show all posts
Showing posts with label OpenStreetMap. Show all posts

Monday, April 16, 2012

GPS navigation with Osmand+



On Friday I went down to Deland, Fl to get my grandfather who was on a fishing trip down there.

When I was first asked about going down there to get him I viewed the map in OpenStreetMap and made some corrections to the fish camp he was staying at there, and made all the appropriate tags.

In the past I have tried to use Osmand+ to route me places and have found it to be all but useless for getting directions.  Since I didn't have any time frame I needed to make it down there I decided I would try the latest version to see how it would perform.

Everything seemed to go very smoothly, thought I am very sure that the route it took me was not the best.  It had me get off after Gainseville, drive east of town, and then head South.  I took its advice since I like taking back-roads when I'm not pressed for time.

About two miles from my destination it tried to take me down a road that ran into a private government area that was blocked off by a fence.  I tried Google Maps and it was doing the exact same thing.

I drove just a few hundred feet past that wrong turn and it rerouted me the correct way.
At my destination I fixed the OSM mapping and filed a bug with Google Maps.  I also walked around the fish camp and made updates based off of observations that could not be easily made from satellite imagery.

I was very happy with the capabilities of Osmand's offline routing mode.  The most recent version of the offline maps for Florida did not have the fixes I had made for the fish camp the previous week, but that was alright as prioprietary maps can take years to have updates and receiving the updates can be costly.


Tuesday, January 10, 2012

Changing priorities for a bit.

I'm going to cease work on beefing up the Tallahassee map and fixing MapDust bug in Florida to start addressing area that the OSM Inspector shows needs to be addressed before the licensing change.  Given that this is time sensitive it will be my new effort up until April 1.

Thursday, December 15, 2011

Finding duplicate MapDust bugs.


One big issue that the MapQuest app seems to have is that it sometimes will report a single button multiple times at the exact same lat/long. Often one of the duplicates will have the description the user entered, if one was entered at all, and the other bugs will have seemingly random Types, with the default text for that type in the bug report.

In my effort to squash all reported in Florida, sometimes I just go looking for invalid bugs so that when I'm in the mood to do some real fixing its easier to find actual problems. In that spirit I have whipped up a quick way to find duplicate bugs so that the dupes can easily be marked invalid so that the original can later be individually verified.

To find duplicate bugs, first download the latest MySQL database extract from http://www.mapdust.com/dumps/latest_mapdust.sql.tar.gz Unzip the database file in the tarball to wherever is convenient for you.

Install MySQL on your system and then run the following command:
CREATE DATABASE mapdust

Now edit the database extract and add the following to the first line. 
use mapdust;

Now, while in the same directory as the extract file run the following command
mysql -u root -ppassword < latest_mapdust.sql

Replace the word password above with your root password, being careful to not put a space between -p and your password.

Now we are ready to query our new database for duplicates.
use mapdust;
SELECT id,
    latitude,
    longitude,
    bug_count

    FROM
    (
        select latitude, 
            longitude, 
            count(*) bug_count 
            FROM osmexportbug 
            GROUP BY latitude, 
                longitude 
    ) foo
        JOIN osmexportbug 
            USING (latitude, longitude)
    WHERE bug_count > 1
        ORDER BY bug_count, 
            id;

You should now have the bug number and lat/long of the duplicates. The ones that belong together are easy to spot because they are sequentially together. I use the following query to only find duplicates in Florida.
SELECT id,
    latitude,
    longitude,
    bug_count
    FROM     ( 
        select latitude, 
            longitude, 
            count(*) bug_count 
            FROM osmexportbug 
            WHERE administrative_area = 'Florida' 
            GROUP BY latitude, 
                longitude 
    ) foo 
        JOIN osmexportbug 
            USING (latitude, longitude) 
    WHERE bug_count > 1 
    ORDER BY bug_count, 
        id;

After locating a strand of duplicate bugs I go through and mark all but the lowest numbered bug as a duplicate. I use language like the following:
Duplicate of bug 85064.
http://www.mapdust.com/detail/85064


Later when I come across the original bug, I'll only have the one to verify and squash, not a bunch after it to go through and tediously mark invalid.

I hope this helps any other bug squashers out there looking to address the bugs the awesome MapQuest users are out there reporting for us.

Sunday, December 11, 2011

Out of town mapping

This weekend I went down to the West Palm Beach area to celebrate my sister-in-laws graduation from FAU. My father-in-law noticed that his son's neighborhood was not completely mapped in either Bing or on Google. Bing is missing some streets, and Google is missing some street names. I pulled up OSM and the situation was even worse. No streets where mapped at all. Apparently this place was only built around two years ago.

Like a good OSMer, I began tracing the missing streets using the areal imagery. When I was done with that I downloaded the area into JOSM, loaded the kids into the car, and drove around, marking the names of the streets as we campused the neighborhood. When we got back we uploaded the edit, and now OSM has the only 100% mapping of the area.

I mapped some other missing streets, but there is no chance of me getting the chance to visit the areas to get street names, mostly because of time issues, but also, these are gated communities where I wouldn't be allowed in to anyways.

Sunday, October 2, 2011

Big Fix

I came upon MapDust bug 209335, http://www.mapdust.com/detail/209335, which noted some misplaced and missing streets. Further review of satellite imagery showed that there was a massive issue in this area where the Tiger data was missing lots of streets, and the streets it did have where grossly misplaced and mis-shaped. The problem only seemed to exist on Pleasent Hill Road north of Southport Road and South of John Young Parkway, but that area is pretty large.

Anyhow, after many hours of fixing, redrawing, and adding roads, I was finally able to close out the bug today.

After the hiatus of squashing a bunch of MapDust bugs, and marking many more invalid, I'm back to mapping out my homeland. I've already fixed up a bunch of roads, and added others. Soon I will need to do some on-the-ground checking to get some road names and find out what's going on with roads that, from the aerial imagery, don't seem to actually exist.

Saturday, September 3, 2011

Squashing bugs

Today I spent a good deal of time addressing bugs in Florida reported mapdust.com MapDust is a great tool for crowd-sourcing the location of problems, and providing the tools for cartographers to address them. There are a number of issues with MapDust. There is no ability to have a back-and-forth dialogue with the person who reported the issue. Lots of bugs do not contain sufficient information to know what issue the reporter may have been wanting resolved. Sometimes a scan of the area with the Bing aerial imagery where the bug report was filed will show where there could be improvements made. In those scenerios I just do cleanup of the area and then close the bug.

I have cleared out all bugs in the Florida Panhandle, and did spent most of my efforts today in South-West Florida. There where lots of very useful bug reports in the Fort Meyers and Naples area, so I addressed every single one of them. I would like to see a day where Florida's bug count was at zero.

I think having a fast turn-around time for bug resolution will help with the perception that OSM is a good source for mapping data, and that it's open nature empowers problems to be resolved quicker than proprietary mappers can provide.

Tuesday, August 30, 2011

On-the-ground work

The vast majority of my mapping work is done via my computer chair with the Bing imagery. I've been going over South-East Tallahassee roads very thoroughly. My existing knowledge of the area, plus the Bing imagery allows me to get a lot of very accurate work done fast. 
However, there have been a number of questions I couldn't answer. Lots of churches where brought in via the GNIS import, and they need to be individually verified to 1. Actually exist and 2. Be named correctly.

Today I stayed home with my sick daughter, and I used the opportunity to drive around and get some on-the-ground mapping done. I was able to remove some streets I was 95% sure didn't exist. I added some detail to some schools in the area. I removed some churches that didn't exist, renamed churches that had changed denominations and names, and I did some other minor cleanup and fixing.

I was able to accomplish this with my CR-48 Chrome Laptop, and my rooted Droid Incredible's Internet access. This setup isn't nearly as nice as my desktop computer with DSL.


Downloading tiles took much longer, and Flash on the laptop isn't nearly as fast. The mediocre trackpad was another issue of frustration. However, with some time and patience, and with my daughter quite content playing her new 3DS, I got some good mapping done.

When I got home I went back and added some better detail to a local city park, and made other touch-ups easier done at home, but from knowledge gained during my field mapping. I've got a few more roads I need to visually verify and I will consider my work, for now, on the area to be done.

Saturday, August 20, 2011

Time to get some real detail

Today I finished reviewing all of the primary and secondary roads in Tallahassee. Name abbreviations have been removed, positions have been corrected, dual-carriage ways have been separated out, and other relevant meta-data has been added.
 
At this point I'm going to move on to cleaning up neighborhoods, adding area detail such as marking wooded areas and lakes, and removing erroneous roads. The TIGER import has lots of residential roads that don't exist in real life, and plenty of other roads just grossly misplaced. Sometimes there are named streets that don't even exist. 

I've also added detail for a few schools around town.

I find the maps look truly beautiful when an area has a high level of detail added. I don't think I will be adding too many building, except when working on schools. At some point I will probably tackle FSU and FAMU, though those will be major undertakings. I've already got some FSU mapped out.

The good news is that if you are passing through Tallahassee with your GPS and OSM data, you can have a high level of confidence that you will be guided through without any sort of crazy bad TIGER data causing you heartache.

Friday, July 29, 2011

Finally getting into real mapping

I've been mapping for quite some time, spending a lot of resources getting a ridiculous amount of detail in the neighborhood I work. That work is 99% done, and I think I've got a pretty good sense of mapping for OSM.

Yesterday I started working on combing through Tallahassee via the Bing Satellite imagery and fixing things up. There's a lot of residential roads grossly misplaced, and dual carriageways that need to be split out as such.

My plan of attack is to make sure the major roads in Tallahassee are accurately mapped so that at the very least, routing applications could properly take people through the major parts of Tallahassee properly.

I'm debating spending resources on also marking POIs, such as gas stations and grocery stores. That is, of course, very nice to have, but could take significant time away from getting the streets down correctly.