Recent diary entries
We represent the OSM community in Nepal and we are working on a project which include mapping kiln that produce bricks in our capital city. Pollution especially air pollution has been a main issue for quite some time in Kathmandu, capital in Nepal. According to Environmental Pollution Index 2014 published by Yale University, Nepal ranked second last after Bangladesh in terms of air quality and its effect to human health http://www.cen.org.np/uploaded/AQ%20Status%20and%20Managment%20in%20KV_Maya%20Factsheet%205.pdf and toxic chemicals such as polyaromatic hydrocarbons (PAH) from combustion in brick kilns and diesel vehicles (MOEST, 2005) adds to it. We need to map the data related to brick kilns and keep it open (upload to osm) for analysis of the data for possible actions. There is an existing tag man_made = kiln and product = bricks but it is not rendered in openstreetmap site. There are 98 users of the tag man_made = kiln according http://taginfo.openstreetmap.org/tags/man_made=kiln
We want these to be visible in the openstreetmap so how can this feature can be rendered in the map?
Always making edits surrounding edits of railroads with gps traces and Tiger Road data on. I often find data that has not been entered this way.
I'm trying to improve the accuracy of the mapped features in Smoke Bluffs Park in Squamish. This is a very popular rock-climbing area with many documented and bolted routes, so I'd like to be able to use a GPS to find a particular climb. Although the bluffs themselves are mostly exposed, most of the approach trails to top and bottom are in forest, and don't show up on the common satellite photo sites. I was using 3 different GPS sets here - a Garmin GLO bluetooth unit talking to a Nokia N810 tablet, an Asus ME173X tablet with builtin GPS, and a Nokia E71 phone with builtin GPS. I had assumed the GLO (GPS+GLONASS) would be most accurate - it is sold as a GPS, tracks more satellites and has a faster update rate. But when I checked the tracks recorded on October 11th, there are places where "going" and "returning" traces diverge, walking the same trail. I returned on October 13th to check some features, with 3 GPS sets running, and got 3 different traces. In some cases these are far enough apart that I'm no longer sure which trail I was on at the time - the trails are in some cases quite close together. At one point I tried leaving the GLO at a fixed location, and walking twice around a loop with the Asus in order to later subtract the traces and get DGPS accuracy, but this was not very successful - the corrected trace was little better than the original. I'm not sure if I would get better results from two identical units, e.g. two GLOs.
Has anyone any suggestions ? Would a second GLO used for DGPS post-process be better ?
Edit places in Koreng while making some corrections
First edits of the Mills/Virginia area. Updated the construction area to include. I plan on doing field papers and updating a large stretch of Mills and Princeton in the area since the weather is a lot nicer now.
I am editing in HOT task "#672 - Ebola Outbreak, Port Loko, Bombali districts, road network", and I am seeing these odd somewhat circular features on the ground. This screenshot is about 600 ft (180 m) wide. Groups of them look a bit like honeycombs. What are these?
I suspect that they are man-made and are something agricultural, but I am also not seeing buildings nearby. So, it is not clear. The line is a tertiary road and probably not paved. Any guesses?
I’m interested to see how well this could be used to update OpenStreetMap. I always find it easier to be outdoors surveying, and others can spend a lot more time than me editing at the computer. I’ve taken photos along the High Street road through Langley Moor where shops & other features aren’t mapped. If anyone would like to add them, the Mapillary iD editor might be useful. Keeping the map quality high involves working together, so I’ll be ready to answer local-knowledge questions and to have a quick verifying look at the editing work. Let’s try out the possibilities.
Full blog post with links: http://www.livingwithdragons.com/2014/09/maps-now-with-added-photos
Please let me know if you do any editing there as a result. I'm considering if it's worth collecting photos on a larger-scale.
I'm looking through the OSM database and finding a lot of weird quirks in the admin_hierachy. There are lots of things that are tagged admin_level=2 that I don't think are quite right. If you get a message from me, it might be because of that.
He was mapping for a project at college. I had a short talk with him. The students in his class are spread all over town and researching the change that happens when small alleyways close. If I understood it correctly. Why aren't the universities and colleges support their students in contributing to Open Street Maps? He said they gather all this data. And then nothing. It just sits at their homes and does nothing. I really hope he will check OSM out and will find it a satisfying way to share the data.
I've been a bit more away from osm in the last week than I planned so apologies for those waiting for bit from me. I've not forgotten!
I'm planning to do the whole of wash common's roads in a big stint very soon.
I began in the area before I'd learnt about area highways. so the results became a bit strange (footpaths narrow and road surfaces very wide creating mismatchings and dislocated sidewalk features that tried to join the footpaths. Then when I tried to add area highways using the early area=highway type tagging it fell foul of mentors auto-validator and the "corrections actually messed up in some renders as mentor tagged the with a lot of highway tags to confuse things. The key reason why they weren't suppose to be added in the first place. So I gave up on Wash common for a while to see if mentor would finish the site off, (I had other fish to fry too). But nothing seems to have been added and parts are just looking like a mess so I need to go back and get it done properly.
As area highways and sidewalk tagging seem to have been a moving target to draw with I was going to put a general question out on the help wiki to find out what the consensus is at the moment on this apparently such an awkward feature (most maps I commercially use just use vectors to show edges of things and then the space between the "edges" of the same type become areas or a seeding dot or simplified routing line to carry the pathing logic in a cheap way.
Features I want to look at is:-
Roadscape feature edges: the sides of islands, verges and special contraflow barriers Roadscape surfacing areas: patches of surface treatments from special grip and colour coats (common in the UK the former near problem junctions, and the latter to help highlight use restrictions - through to - major surface material changes (such as a bare concrete busstop or parking bay alongside a tarmac carriageway - or on "sidewalks" the awkward [see wheeled carts etc] patches of cobbling styles at entrances and by certain buildings the interrupt the smoother paving slabs on the rest of the sidewalk. Parking bay areas: some jurisdictions like the ones I map draw very specific boxes on the highway that parking is allowed and nowhere else [for the stretch they cover - however short]. So it would be nice to convey the areas on the highway you could park when doing a area for the featured highway. Lanes areas: These could be special rules spaces like fire lanes in the U.S. or bus, cycle, taxi only lane in the UK and elsewhere. -- or by simple extension defined lanes in the carriageway [often when painted to rules] :: features about lane boundary crossing rule makings could be added on the edges of these if people wanted to add that type of information.
Highway boundaries physical: the limits of landuse dedicated to the highway inclusive of all the features including ditches and verges - solves the strange debate of what to map other landuse areas to when the edge runs alongside the road. Highway boundaries legal: the edge limits of what a highway authority has the power allow the right of passage to the public or to control parking etc isn't always the same thing as the edge of a sidewalk or fence line sometimes neighbouring property places more pavement on the edge of the highway to improve the interface between the site and highway users such outside shops or for private parking. Sometimes these get marked in special ways while others they are only given in landowner to landowner agreements such as rents paid to allow the highway use of parts of private land that is only defined in a contract between the parties and nothing is on the road. Carriageway edges:it might be useful to have a logical way to bond a relationship of lanes or just to map a carriageway without its lanes to start with.
Crossing limits: there can be highly marked areas on some roads where pedestrians (and sometimes bicycles and horses are supposed to cross in. rendering these can improve user comprehension (especially when multipathing is defined (horse and cycle segregation on the crossing)). it may also render well to similar features like bridleways approaching the road.
There seems also a lot of evidence that defining junction space on both carriageways and separately out the highway boundaries is also important for some users the later is often used like a navigating place name especially when roads are not named but the junctions are instead. [look in the wiki for examples about these]
The more to add street furniture already in osm in more precise location becomes easier to like lamps, postboxes, telephone boxes and kiosks.
When would this be most relevant? When guiding pedestrians (especially the disabled), parking motorists, and when make entrance maps for flyers and brochures. It also looks good alongside transition to indoor mapping systems at normally smaller scales.
The way to look at it is to stand next to a busy road and think of as not just a road but imagine it was part of a park (as in the green grass urban variety) and to map the complex of features you can find in the roadscape around you.
a god exaple I found was this http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area and this earlier started proposal that takes up were the approach I first adopted left off https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway.
http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way is also useful to show how people are also aproaching the problem. I'm out of time tonight but I may try sending this to the help wiki soon to get some feed back by all those that scour that system.
Doing this, mapping these places, very tiring. I know i'm helping and doing something I have never done before is why I continue to map. i thank my teacher for showing an allowing us to do this its pretty cool.
I want to do a few tiny mapping projects in Maine, because I have some local knowledge, and I know people there who need maps. But I've run into a number of issues, and it has been suggested that I should write these up for a larger audience.
The county borders in Maine are wildly inaccurate, at least along the coast. They're based on a low-res trace of the shoreline, which has several problems:
- You get a lot of cluttered borders deep within a county.
- The borders swerve randomly all over coastal islands. This is ugly, and incorrect.
- Many smaller islands are omitted entirely.
Here's a sample. Every piece of land on this map actually falls within the county line, and I'd imagine that the ocean is under county jurisdiction as well:
Now, we actually have pretty accurate county data in various GNIS and TIGER fields, if we know how to interpret it. Let's set up a JSOM filter to exclude everything but Lincoln county data and the border line:
-("gnis:county_id"="015" | "gnis:County_num"="015" | "tiger:county" = "Lincoln, ME" | border_type = "county")
This gives us a pretty decent county boundary:
You can see where I started cleaning up the county borders by hand on the left side of the map, relying on GNIS county data on the mid-river islands to get it approximately right.
We either need to find a better data source, or we need to redraw the county lines using GNIS/TIGER data. Even rough, hand-drawn county lines would be more accurate than what we have now.
Nominatim and town lines
Here's another map. Everything on this map should have "addr:city=Boothbay". But as you can see, the actual town of Boothbay is marked using a point:
The problem arises because of "Trevett". This is local Boothbay post office, not a real town. But Nominatim has decided that many roads are in "Trevett", and it can't find them if you search for the actual postal addresses that use "Boothbay."
When you combine the lack of town lines with the bad county lines, OpenStreetMap won't be able to locate the home addresses for people who live near the Maine coast. And this will make it hard to enlist contributors in these areas: We need a certain minimum level of usability before people will try to suggest improvements.
So what do people think? Is it better to have dodgy hand-drawn borders than what we have now? Or should we find a better data source? And if so, where?
And so is Potlatch... just about. (Insert obvious Flash reference here.)
Potlatch 2's core purposes are (a) being an intermediate-level editor and (b) annoying Germans. It's never going to get major new functionality or important rewrites, but for those of us happily using it, I've always intended to add and fix little things over time.
In the summer it gained support for the editor-imagery-index project, which provides a central list of background imagery suitable for tracing. Today it has a couple of improvements to the long-standing feature where you shift-click away from a way to add a new point (roughly comparable to JOSM's "Improve Way Accuracy" mode, but we don't do modes round here) - which is a really useful technique for TIGER fixup.
I've also added the ability to memorise tag combinations and recall them by a single keypress. Very simple: press shift and a function key to memorise the tags from the current selection. From then on, pressing that function key will add the tags to the selected items. (Those with long memories may remember this is a Potlatch 1 feature, and one I've always meant to add to P2!)
I have a couple of larger features which are 90% coded but were never quite finished, both firmly "intermediate-level" tools. As and when I get the time, I'm hoping to finally finish them off and get them out there.
I am getting tired fixing the automated notes. For every river crossing, some darned program will put a river name note. For every overpass, it will put no waiting on both sides of the bridge. Then there is the "Go ahead" notes popping up here and there.
Luckily, our main North South highway is only few hundred kilometers long. God help me if it is as long as I-40...
Express your opinion about the relation "type=person" here:
This is also questioning the limits of the project (what has to go into OSM and what not)
Warning: This post makes absolutely no sense to anyone outside the United States, or to anyone who relies on a mode of transportation that uses a sane numbering scheme.
Development on the OSM U.S. shield renderer seems to have stalled a bit, and my request to render pictoral route shields on the Standard stylesheet is effectively tabled for now. There doesn’t seem to be a whole lot to get excited about on the shield rendering front.
Just to bide my time, I decided to approach route shields from the other direction, using OpenStreetMap’s coverage of the Cincinnati Tri-State area as a starting point. Slapping shields in random locations all over a road map is so… functional. So let’s ditch the map, fire up TileMill, and let the shields do the talking:
A bit of a mess, isn’t it? It’s even worse when you zoom out:
But pan around, and you might start to notice some patterns if you’re from the area. You can make out the most prominent highways. Here’s a map Nate made from OSM data, for comparison:
You can make out the Ohio–Kentucky state line where the state route shields in the shape of Ohio turn into plain old circles:
So what’s going on? Each shield on the grid indicates the nearest Interstate, U.S. route, or state route, with an understandable bias towards highways over surface streets. A shield isn’t necessarily positioned along the route it indicates; rather, it just happens that no other route is closer. That property gives rise to an interesting phenomenon that I’ll take the liberty of calling a routeshed. Much like a watershed, a routeshed encompasses the area in which cars naturally flow toward a single route. OK, that sounds so ridiculous it belongs in a Wikipedia article. But this is what the sparse terrain of western Hamilton County looks like:
If you’re as sleep-deprived as I am, it does kinda-sorta look like a watershed.
Here’s the full slippy map.
Credits: Road data from OpenStreetMap contributors, mostly me, Nate, and NE2. Shield blanks from Wikimedia Commons users SPUI, Ltljltlj, Fredddie, and Scott5114. Shield labels set in Roadgeek 2005 Series C and D. Code under the MIT license; tiles under Creative Commons Attribution 4.0.
I've updated the statistics that I regularly produce from our changeset dump, see stats page on wiki.openstreetmap.org, to the end of Q3 2014 numbers.
The well known trends continue with continuous growth in every category with a total of 447'883 contributors. Of special note is
showing that at the end of the third quarter we have already had slightly more active contributors than in the full year 2013.
August 2014 showed the 2nd highest increase in contributors in the history of the project with over 10'700 new mappers joining OpenStreetMap. It is not unwarranted speculation that this was due to the tenth anniversary celebrations.
Blvd, Dr, and ave are common abbreviations for Boulevard, Drive and Avenue.
Many times people search for ABC blvd rather than ABC Boulevard. Can we make one a synonim of the other and then merge all Blvd and Boulevard together?
In the last days I mailed a lot of people about unusual values in their fire_hydrant tagging. The most important one was fire_hydrant:type, where some more or less unique values are already gone and replaced by the more common tagging. One nice thing were 3 things that were in fact no emergency=fire_hydrant, but emergency=water_tank. But since the original contributor was unsure on how exactly to tag these things he added an image tag to each of them, showing a photo. This way I could easily point him to the right direction, and as a nice side effect one of these images can now be seen on the wiki page for emergency=water_tank. Until now I only mailed those people that I was rather sure to understand either German or English and left out the Russian, Spanish (could also be Portugese or Italian, no idea), and French ones.
In the process of cleaning things up I learned that the New Tags JOSM presets, which I didn't know about before, introduced wrong tagging. It wrote the German names to the tag field instead of the English ones. Since this isn't exactly a new tag and JOSM already has a working template for this, I simply removed emergency=fire_hydrant from this presets.
Today I made the mistake to look into fire_hydrant:position values. This is probably unusable for any automated application, at least outside of your local clean area. There is a huge amount of inconsistent tagging in all sorts of languages. If I were really bored I would try to get clearance for a mechanical edit and would at start with deleting every fire_hydrant:* attribute that has an empty value. But sadly I'm not that bored, so any volunteers are welcome.
Today I tidied up a bit of the land use areas around Edsån (a stream) which recently has been modified in RL to have a meandering path. I have done some GPS track walks around it to get the rough outline, and the new outline can of course be adjusted when the new air photography is available.