Recent diary entries
It took me several years but I've made it to my 1000th edit!
I've found the parking lot signs aren't that useful on the University of Wisconsin campus, if you're not familiar with the various lots. Some lots require a permit, and some are metered parking. If you're permit-less and looking for somewhere to park, the signs at the entryway to each lot are not that useful from a distance. Each has a red band at the top with white lettering indicating either "PERMIT REQUIRED" or "METERS ENFORCED" above the common "Monday-Friday, 7am-4:30pm". From a distance, since both are red bands, and two words long, it's hard to distinguish at a glance, before turning into the lot itself.
The UW parking map (http://transportation.wisc.edu/files/14_15ParkingMap.jpg) isn't much more helpful, only differentiating the permit-vs.-meter lots with a "M" symbol on the metered lots.
So, I started tagging the parking lots in OpenStreetMap with the proper "access" tags, and hopefully some parking app can parse them and make an easier parking experience while on-campus.
The permit-required lots are:
access=private access:conditional=public @ Mo-Fr 00:00-07:00,16:30-24:00; Sa-Su 00:00-24:00
And the metered lots are:
access=public fee=yes @ Mo-Fr 07:00-16:30
I've moved the townlands web application to: http://www.townlands.ie/
The source code is on github: https://github.com/rory/osm-irish-townlands/
Feel free to request new features or report problems via github's 'issues': https://github.com/rory/osm-irish-townlands/issues?state=open
We are a young GIS development organization and have begun further densifying Nagpur and Mumbai cities in India, for our own and the mapping community benefit.
The idea is to spend about an hour or so on a daily basis adding markers for major city areas first, then digging into each area and identifying landmarks (mostly used for providing verbal directions in India, notorious for lack of a systematic address format) and streets. The hope is that folks and our devs will be able to build on this to provide geocoding (using opensource geocoding engines such as OpenCage Geocoders that use OSM) in our mapping apps.
Why Nagpur? Its a so called tier 2 city in India. Tier 1 cities are those like Mumbai, New Delhi, Chennai etc with bigger economies and tech industries. Nagpur is growing in all these areas too, and with good and developing infrastructure, is fast becoming prominent on the investment map. Its also my hometown ;-)
We are of course looking for volunteers from various other cities in India, to chip in during their free time. You know, when you are watching that game on TV and if side by side you could also identify some well known spots in your neighborhood or your city on OSM, that'd help everyone a great deal.
Thanks and have a great time! Ajit
I've created a new static web page based on GitHub pages for the local Ottawa mappers community here.
My intention with this to make it easier for local folks to connect with the local mapping parties as well as a handy resource.
Let me know what you think! Pull requests to improve or other ideas are always welcome:)
We hope to map all areas in Uganda but lots of challenges are on our necks and these include lack of enough resources to use during our mapping sessions and these include the gps devices,computers and cameras for capturing information during the process
A Comment from BlueTiger on 3 July 2014 at 14:14 in another entry; " Most of the times when I travel I will leave the OSMTracker running and update new POIs. At times I have skipped uploading POIs as they don't have proper tags in OSM. Unfortunately I have taken a bad choice here, I should have updated them anyway and requested for new tags."
I've seen a few tags that were not "proper" in an OSM sense .. but they make sense if you know what is there. Unfortunately getting somethings in to be "proper" in OSM looks to me to be difficult due to the numbers and location game e.g. Radio Telescope. While other things that are not consistent get through - e.g. highway=footpath and highway=path. So I'm inclined to tag all things I consider important in either a navigational sense or a facility. Make a tag note= with some explanation if necessary. This way the data is there .. even if used at this time. I'd rather have the data recorded rather than thrown away. The "improper" tag can be changed latter if a more appropriate tag is available.
NOTE: This post is mostly for my reference, might not make a lot of sense for other folks -- but thought I'd put this out there in case you're interested in the intricacies of TIGER data in the US.
Quick post to highlight some charts as I'm doing research on this topic:
- Number of ways with a highway tag, and counting a way as one using unique "name" tags. TIGER counties are the ones that complete "good" TIGER data, while control counties are those that got missing TIGER data.
- Same chart, but only for highway class = 1 (i.e. motorway and trunk). Seems like someone added a lot of new class 1 highways in 2010q4
- Same chart, but only for highway class = 4 (i.e. cycleways etc). Note that TIGER was not a source for many highways of this type. Note how the control regions got a spike while the TIGER regions did not.
- Same chart, but only for highway class = 3 (i.e. residential / tertiary etc).
How about reading the local newspaper – especially the business pages – for information useful for updating existing OSM data or preparing a 'To Do' list for when the weather improves.
Examples are:- 1. New shops/businesses opening up or old ones closing down. 2. Perhaps a new building project has just got underway. 3. Who has just moved to new premises? 4. What is happening to that vacant site I noticed the other day? 5. New section of highway opened. 6. Developers advertising sections for sale on new housing subdivisions.
For building sites (tag 'landuse=construction') here are a couple of useful pages from the wiki
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dconstruction http://wiki.openstreetmap.org/wiki/Key:start_date – a future date can be entered to indicate when construction is due to finish. Might be a good idea to make a diary note around that date to check on progress so that a further update can be made.
Another 'wet day' project could be to select a local area and, if you have decent Bing imagery, add building outlines to the map. Select just a block or so and use a bit of caution combined with your local knowledge in case things have changed since the area was photographed. You are then all set to go out on a fine day and gather 'on the ground' details for all these buildings.
Finally, if you use JOSM as your editor, I highly recommend installing the 'Opening Hours' plugin. Once you have checked businesses opening hours on the web you can use this plugin to add the info to the OSM data. It makes a seemingly tedious task so simple.
Here's an example of a Mapillary image and map context:
I have created an account and did some test shooting from my car, using the iPhone app Mapillary provides. This is OK, but I want better quality images. So I am looking at an action camera I can mount in my car and on my bike.
The Garmin VIRB (Elite edition shown):
The GoPro Hero3 (White shown):
- The VIRB seems to have better battery life (important! but could not find any side by side comparisons)
- The basic GoPro Hero3 is less expensive than the basic VIRB
- The Elite edition of the Garmin VIRB has lots of built in sensors: GPS, altimeter, accelerometer - nice, but I am already carrying a GPS wherever I go anyway.
- Both can do automatic time lapse photos at set intervals, which is crucial.
- The VIRB can do 16MP stills, the most expensive Hero3 can do 12MP. This does not necessarily mean better pictures, of course.
- The most expensive Hero3 comes with a remote, which can be convenient if you don't want to time-lapse. For example on long freeway drives where you just want to capture the signs. The VIRB can be remote controlled by certain Garmin devices like the Fenix 2 watch. Both come with smartphone apps that can control the camera as well. Convenience factor is much less though.
- The VIRB has a built in screen. Not sure if that is actually an advantage. What would you use it for?
- Both have wide angle lenses which is important to capture as much in one shot as possible. Specs are sketchy but it looks like the GoPros have a slightly wider angle.
- GoPro has been at this for a lot longer than Garmin.
Here's a comparison of the video side by side. I wouldn't use video mode as much so this is of limited value, but anyway:
iframe embedding does not seem to work - is there a way?)
From what I can see the GoPro wins out by a small margin: sharper and better colors.
What do you use? Any other cameras to consider?
Here in the U.S., we have been using the convention of tagging exit information on the
highway=junction node using the poorly documented
exit_to tag. The rest of the world has been using
destination=, and now that I start to think about this problem more, I can see why.
Let's take this example of the junction of I-70 and the Baltimore beltway I-695.
(Have you used Mapillary? It's pretty awesome and unlike Google Streetview, OpenStreetMap explicitly does have permission to map from the images. It's pretty easy and fun to contribute your own, too.)
How to tag this so that navigation and other software could make sense of it?
Currently, the only relevant tags on the junction node are
ref:right=91A indicating the exit / junction numbers. There is nothing on the `_link' ways to indicate destination.
One way I have seen people map this information in the US is roughly
exit_to:left=I 695 N;New York;Towson and
exit_to:right=I 695 S;Baltimore;Glen Burnie. This is not great for a number of reasons:
- There is no way to distinguish the
I 695 Setc) from the names reliably.
- The US seems to be the only jurisdiction where
exit_toon the junction node is used, the rest of the world uses
If we were to adopt
destination= in the US like everywhere else, most of the signpost information would be on the
_link ways after the junction node. Here is the situation in OSM:
According to the
destination documentation, the first way would get
destination=New York;Towson and the second way would get
So far so good. But there's a few pieces of information that are not captured yet:
1) The exit (junction) numbers 91A and 91B. Oh wait - these were already on the junction node as
ref:right=91A. This works, but intuitively it would make more sense to have this information on the
_link ways as well. I am not sure how and the wiki does not give any guidance. (Actually it suggests using
ref on the junction node for exit numbers.)
2) The road numbers the exits connect to, in this case I-695 N/S, leading to I-95 N/S.
destination:ref seems to be used for that quite a bit. That would work for I-695 but I don't know how to capture the connection to I-95.
Following the documentation as best I can, this is what I come up with for the highlighted _link ways:
I think this system makes more sense than the
exit_to convention that is poorly documented, doesn't scale well to cover complex cases, and is used nowhere else in the world. The only good reason I can think of why people use it is because it's used much more (about 18,000 times) than
destination= in the U.S. Elsewhere, from what I can see in TagInfo,
destination= is more popular.
The June version of JOSM is now available (a bit late) as version 7287 :)
This version brings some technical enhancements and a lot of bugfixes, here's the changelog:
- Extrude action: add dual alignment mode
- Automatic reloading of local map paint styles and validator rules on file change
- Automatic update for imagery entries using
- Allow setting shortcut for Move Node to Way
- Mac OSX: register JOSM package as
- Remote Control:
- add right- and left-hand traffic database, update roundabout icons (new pseudo-class-condition
number_of_tagsexpression to get number of tags,
printlnto show debugging output
- add right- and left-hand traffic database, update roundabout icons (new pseudo-class-condition
- Presets/Map styles:
- use of new
leaf_cyclekeys in presets, deprecate old
- better rendering of bridges, tunnels, highways, cycleways, turning circles
- use of new
i was using this into the overpass api
[timeout:86400]; (way(34.759984,-12.216797,71.587596,36.298828)[shop];); out meta;
[timeout:86400]; (way(34.759984,-12.216797,71.587596,36.298828)[shop];); /*added by auto repair*/ (._;>;); /*end of auto repair*/ out meta;
While playing around with the changeset data I noticed an interesting pattern. There were some users who had made a lot of contributions to the map, who were nowhere to be seen. A lot of the talk in the community has been on attracting new mappers, but if we're losing existing mappers that is surely a problem, no?
Wondering if this was a big problem, I decided to dig in. Here is what I found -- it doesnt seem to be a HUGE problem at the very top, but there are many mappers who make 10 or 100 changesets that never come back. Note that this is only using data from the USA at the moment.
First thing to notice is the blue line -- these are how many users there are for a minimum number of changesets. 44k users have more than zero changesets, 25k have more than one changeset, 100k have more than 5 changesets and so on. There are only about 273 who have more than 1000 changesets, and I've done my best to get rid of imports so these are likely to be real people, but Im sure a few of these include imports.
Now, how many of these users seem to be lost from OSM? The Orange, Yello and Green bars plot number of users who have not made a single edit within the US in since 2012, 2011 and 2010 respectively. So, for example, looking at the extreme right, of the 273 users who made at least 1000 changesets, 22 have not been seen since 2012, 12 since 2011 and 4 since 2010. The problem is a little bit more acute if you looked at those who made at least 500 changesets. Of this group, about 50 have not been seen since 2012.
Who are these users? And why did we lose them? Was it due to contributor terms or is it just bots which are no longer being deployed?
Here is the list of the top missing mappers that I could find in my data, heavy mapper that have not been seen since 2012! Chime in, in the comments if you have any theories about where these lost souls might be and what we can do to bring them back!
Here at the top 10 users who have at least 500 changesets and have not been since since 2012:
The German OSM Blog just kicked off its 2nd weekly task (Wochenaufgabe). The goal is to encourage mappers to tag a certain POIs during that period.
The first task was to tag bicycle tube vending machines. Over the next two weeks (community wanted a bit more time) we want to improve the coverage of electric charging stations.
In created a Wiki page to keep track of the tasks and make it easier for non-German mappers to take part:
The OpenStreetMap database is particularly suited to create MTB Orienteering maps (unlike foot orienteering, pretty much everything needed for MTB'O is standard mapping in OSM, at least for recreational and training purposes).
Ruleset, icons, and scripts here: https://github.com/hdevillepoix/OSM-MTBO-Maperitive Please submit suggestions on github project.
Does anyone have an idea how long it takes to move data from the web version of OSM to mobile version (Maps with me)? I have been updating in several countries lately and I cant wait to see my changes in Maps with me! I has been at least three months since the first edit.
Cheers from Italy! (Im updating Perugia now:-)
I made some visualizations of the nodes density of roads in OpenStreetMap
For Romania, there where 379.445 ways that generated over 4.7 milions points that where counted in a grid of over 31000 polygons , with area between 7.43 square kilometers to 8.08 square kilometers
Zoom Out - 14000x9900 pixels Middle zoom Close zoom
2048 OpenStreetMap style density map Glitchy OpenStreetMap density style map
All the images can be downloaded from my Dropbox public folder https://www.dropbox.com/sh/qpgi10q3b62s5c0/AADN0qUyY9x3bNsHQlD0NRB5a?lst
This would not be possible to made in old QGIS 2.2, 2,0 it would have taken 10 times more time. Big thanks for all the dev that are mentaining and improving QGIS
We walked all the way to Eastwood more than once but this time I took my GTA02 with me to trace the path - from Marsden Rd -> Lawson St -> Brush Rd -> Rutledge Rd -> Eastwood. The usual process of downloading/cache the maps using wifi which required SD card (http://gnumen.org/blog/foss/31/03/2011/gps-tracing-using-gta02-u-blox-atr0635-module) went without any glitch. The maps were downloaded using the wifi WPA2(AES). In order to overcome the MAC based pass thru for captive portal of Pfsense entered the MAC addr of netgear in the Pass thru MAC table( risk, I know). BUT when ever the gps is enabled, the GTA02 almost within seconds alarms about low battery which wasn't the case previously but this time only difference that I found was that after every reboot I was not made to configure the SD card and the SD card retained the previous gps traces as well as the map cache(s).. Hmmmm should I call it usual or unusual. I took care of the low battery issue with the Sony cycleenergy Power bank. Don't know why it's behaving in such a manner. ##Some random observation(s)/steps taken - In the flight without the SIM card was able to trace without the battery outage alert for quiet sometime. - After reaching Florida ave the device was not able to retain the battery power even for a day. without GSM sim or any other services disabled. - Placed the sim and replaced the SD card once again.
We came back from Eastwood by Public transport system(BUS) - from Eastwood -> HillView Rd -> Terry Rd -> Marsden Rd
We created a new MapRoulette challenge over at Telenav: Crossing Ways. As always with the Telenav-generated challenges, this one is US only, because we currently only process OpenStreetMap data for the United States. We are working on extending support for other regions.
TL;DR --> On to MapRoulette!!
The Crossing Ways challenge is pretty straightforward and should make for an easy challenge for novice mappers looking for something to fix. It detects ways that cross, but neither way is tagged as a bridge or tunnel. Here is an example:
If you open this up in iD or JOSM, you will be able to tell the required resolution from the aerial imagery:
In this case, the ways should be connected as there is clearly an intersection. Another possibility is that there actually should be a bridge or tunnel tag on either of the ways.
In this particular case, you can see that there actually is a node at the intersection, but it does not connect both ways. In JOSM, it displays as a 'skinny node':
In this case, you can use JOSM's 'Join' function (shortcut 'J') to connect both ways. In iD, a node connecting two ways will be grey, and a regular node will be white:
If you use iD, you can just drag an existing node to the intersection to snap the two ways together, or drag a virtual node to the intersection to create a new intersection node. (Virtual nodes appear between two existing nodes and allow you to quickly create a new node on a way, an example shown below.)
There are currently around 19,000 cases in the US alone, so let's get on fixing these annoying bugs in OSM!