OpenStreetMap

Sanderd17 has commented on the following diary entries

Post When Comment
What's your OpenStreetMap story? 2 months ago

When I got my first android smartphone, it had a GPS, but mobile internet was slow and expensive. So I bumped into MapDroyd (http://wiki.openstreetmap.org/wiki/MapDroyd) which offered offline map rendering for free. Coming from paper maps, that certainly was enough for me ;)

However, when checking out the maps, I saw that my own street had missing parts, next to many other missing streets. Luckily, the app had clear credits, so I could figure out that the maps came from a Wikipedia-like project called OpenStreetMap, and I started tracing roads. At the start, that was done just by running a tracking app in the car, uploading the traces to OSM, and tracing them in Potlatch (adding details from memory).

When the streets I often took were mapped, I also started using the bike to map streets I don't need (like dead-end streets), and more dedicated apps like OSMTracker (that could take pictures).

So I started contributing for some reasons:

  1. The project had data that was usable enough to navigate like on paper maps

  2. There were enough holes in the data to clearly see what could be improved

  3. There were free tools available that used the data with clear credits

Netherland housenumber evaluation available 4 months ago

Oh sorry, I didn't notice the OSM date. It looks like the Flemish OSM data is from December 2014, then those percentages can be correct indeed.

Netherland housenumber evaluation available 4 months ago

I see you also do validation for Flanders, but that most of those have a very low percentage. Any idea how that comes?

F.e. for Staden (which is the most yellow one in West-Flanders), the percentage you give is 85%, while on my tool it's 95.7% (http://crab-import.osm.be/import.html?pcode=8840&loadOsm=true&collapsedSections=export#data)

But worse are the neighbouring municipalities, like in Langemark-Poelkapelle, you give around 20% (not sure why you split up between Langemark and Poelkapelle, it's one municipality), while my tool gives 99.4% (http://crab-import.osm.be/import.html?pcode=8920&loadOsm=true&collapsedSections=export#data)

Note that in Belgium, housenumbers are not unique inside a postal code, but streetnames are unique inside a postal code, and housenumber are unique inside a street. Postal codes map one-to-one with municipalities most of the time. Only big municipalities have more postal codes.

So we do need to compare streetnames, and take abbreviations into account. But you can check out all code and data here: https://github.com/aptum/aptum.github.io

Trying Overpass API 4 months ago
  1. A city is usually no problem. As mentioned in the introduction ( http://wiki.openstreetmap.org/wiki/Overpass_API#Introduction ), you can safely download 5 GB per day without harming the service for others.

  2. You can install your own overpass service if you really like, and keep it updated with the minutely diffs. This may be overdoing it if it's only for your personal use. But if f.e. the complete University campus wants to get big data from Overpass regularly, then you might invest in setting up your own overpass server for your campus. Apart from that, you have the geographic extracts (like Geofabrik you mentioned). And of course, using the main Overpass server is usually no problem.

Charlotte North Carolina 4 months ago

As I see that (at least some) imports from Becker_MN_Import_Acc are reverted, it could also be a reverting problem.

However, I don't think you should invest your time in fixing it.

Either the data comes from a copyrighted source (the source Becker uses for the imports isn't clear at all), then all nodes you connect will have to be deleted.

Or the data comes from a source we can use, then the import can be done again, but properly (with discussion f.e.).

In both cases, just deleting all orphan nodes would be best.

Counting cross-border roads 4 months ago

There are some border cases that you need to take into account however.

Dual-carriage ways are normally mapped as two roads in OSM, and it also happens that roads are exactly on the border between two countries (f.e. http://osm.org/#map=16/50.7190/2.8334), depending on how it's mapped, and how you calculate intersections, this will return different results.

Missing city in Hungary 5 months ago

When you search, you must see a button saying "search village or postal code" or something similar.

You need to press that button before you can find smaller villages.

Apart from that, the diaries aren't really a help site (there's no way to follow up comments, and the questions just disappear in the history), and there's a separation between OSM (the data) and OsmAnd (the app). When you have problems with osmand, it's better to look on their site. I'm sure this question has be asked and answered a dozen of times there.

Observations during a HOT task 5 months ago

Quite often, you'd be surprised how wide paths actually are. Very often, treetops cover a big part of the path, but it's perfectly possible to drive under the treetop with a vehicle.

It's safe to assume that you can always reach a village with a car, so the most important trail leading to it should be at least highway=unclassified.

Connecting roads to residential areas is indeed no good practice, and it shouldn't be the local's job to finish this.

Categorising paths 5 months ago

Ugh, and of course, those examples went missing completely. Here is that paragraph again:

I'm thinking about stuff like having a path=* key like

  • path=forest_trail -> A natural trail through a forest, expect it to be muddy, with tree roots sticking out, and likely steep or slippery, unless the details tell otherwise

  • path=forest_path -> A man-made path through a forest, thus with a good surface, however, it's still likely to be steep, and leaves can make it slippery. Sometimes roots also grow through the pavement.

  • path=grass_trail -> A path through or along meadows. Generally flat, but quite often wet

  • path=park_path -> Flat path, with a good survace (compacted gravel or paved), and a nice scenery * path=city_shortcut -> flat path with a good surface, but in-between buildings or hedges. It's quiet, but doesn't have a nice scenery.

Categorising paths 5 months ago

I'm personally not a big fan of coded hierarchies. They tend to fail miserably.

Even hierarchies coded in a human language, and used by everyone (like the primary-secondary-tertiary classification) fail quite often. People need to invest a big amount of time in them to understand them. So newbies get them wrong a lot.

However, I agree that highway=path is missing information, it would be better to give names to paths instead of codes.

I'm thinking about stuff like having a path=* key like * path=forest_trail -> A natural trail through a forest, expect it to be muddy, with tree roots sticking out, and likely steep or slippery, unless the details tell otherwise * path=forest_path -> A man-made path through a forest, thus with a good surface, however, it's still likely to be steep, and leaves can make it slippery. Sometimes roots also grow through the pavement. * path=grass_trail -> A path through or along meadows. Generally flat, but quite often wet * path=park_path -> Flat path, with a good survace (compacted gravel or paved), and a nice scenery * path=city_shortcut -> flat path with a good surface, but in-between buildings or hedges. It's quiet, but doesn't have a nice scenery.

Note that this is not a final proposal, it needs someone to actually check which paths exist (both rural and urban), and to see how the classification can be worded easily. Since I live in a flat country, I have only experience with the flat type of paths. Thus for me, the surface is the most important (you can't go on a surface=dirt path without boots in the winter, it's just too muddy).

ATMs in Belgium 5 months ago

Sometimes, banks don't want that you copy it. They're sometimes afraid that you'll copy the data, and then, after a few years, it's outdated but people still use it.

When someone searches a bank using outdated data, he can become frustrated when the bank isn't there anymore. So some banks want to be protected against that, and try to limit copying.

So that's why banks might be reluctant. However, surveyed data can have the same problems, and banks can't stop us from surveying. So their sort of protection isn't too clear.

Note that this also counts for other shops, it's the sort of answer I got a few times when asking to use a shop DB. I had to make sure I kept updating it in OSM (and sign a contract for it). But of course, I couldn't guarantee that.

About it being an import or not, I think, as long as you check every thing you add via aerial imagery, it's more armchair mapping than an import. So I'm certainly not against this practice.

Busroutes in Brugge 5 months ago

Hmm

I also mapped a few bus routes in the past (but I found it hard to map a complete town), and AFAICS, Jo did leave these stops where I put them. So it looks like he did treat the existing data with care.

There were other problems though. Like some inaccurate positions for bus certain stops he added. But I had no idea there was a problem with data being outdated.

Of course, when a bus route is deleted, there's no existing data, so I guess Jo just imported that.

Busroutes in Brugge 5 months ago

You should probably drop by on the Belgian mailing list (http://wiki.openstreetmap.org/wiki/Mailing_Lists)

Jo (Polyglot) is active with maintaining bus routes, he uses data from de Lijn. I guess cooperating would be best, else you start destroying each others work.

First Contributions 5 months ago

Thanks for the contributions, it's looking good so far.

I do notice that you added an already existing POI.

Here you see a building (added 1 year ago) with a restaurant tag and cuisine "chicken", however, no name http://www.openstreetmap.org/way/225494196

And you added the following point, in the same building, with the name Chick-fil-A: http://www.openstreetmap.org/node/3369588937

As both chicken restaurants are so close to each other, I guess it's pointing to the same restaurant. Since there should only be one representation of it (so we can count the number of restaurants per city f.e.), one of the two should be deleted, and tags merged.

You may notice that it's not uncommon to tag POI on buildings. When you tag it on a building, there's added information (f.e. the size of the restaurant, a logical connection to the different entrances, ...). However, if a building isn't completely used by that POI, it should probably be tagged on a node.

But thanks again for contributing valuable information.

Mapping Parcel Data in Canada 5 months ago

Do you know that there's a lot of discussion whether parcel data belongs in OSM?

First of all, there' the "ground verification" that's very hard with parcel data. We need to trust the governments that give us the data.

Secondly, parcel data updates a lot (parcels get split or merged). It's even hard to maintain this in the governmental database, so it's very hard to do this on OSM.

http://wiki.openstreetmap.org/wiki/Parcel

It's not because you have accurate data that you have to upload all of them in OSM 5 months ago

There are different factors involved when it comes to precision. I isn't enough that your sensor is precise.

First of all, it matters how precise you hold the device. If you have a 2cm accurate sensor, it's rather easy for the human hand to wiggle 2 cm, and thus cause an extra precision node. In fact, I see that in this data, some points are even there when there's no wiggle at all (or something lower than we're able to represent in OSM).

Then you also have the changing nature of things. When grass lives in a good environment, it will take several cm of the sandbox per year. If the grass doesn't grow well there, more ground will turn into sand over the years. So if you map something natural up to 5cm precise, it will only be true for a year or two. It's even worse for water, which may change on a daily basis.

Thus, to answer your question: I don't think OSM will ever become as precise as the data mapped there. There's a natural limit to our precision. Any data we add beyond that natural precision will just give us the fake idea of improving the data (and it puts a burden on the data customers).

It's not because you have accurate data that you have to upload all of them in OSM 5 months ago

The simplify way algorithm uses (most likely) the Douglas-Peuker algorithm. That algorithm is clever enough to not just evenly space nodes along the line, but it removes the nodes that influence the shape as little as possible. This is done by comparing how big the area difference is when you delete or keep a node.

As such, the end results are that it deletes the nodes that don't change the shape, but it keeps the nodes close enough in a sharp turn. Of course, finding the right precision value is a bit of trial-and-error, as it differs per case.

It's not because you have accurate data that you have to upload all of them in OSM 5 months ago

Also, it looks like most of the features he added were already present in the data, but just not tagged with landuse=*, so they weren't rendered.

It's not because you have accurate data that you have to upload all of them in OSM 5 months ago

Ugh, it's even worse than that, he even tagged all nodes: http://www.openstreetmap.org/node/3367453367

Since he wants high-precision data, the default settings for simplify-way are a bit too coarse. So someone who knows to enter finer settings, that would be very nice.

And of course, null-angle or almost null-angle nodes should be deleted, but sharp turns can still benefit from a node every 30 cm. But this is something algorithms (like the one in simplify-way) do rather well.

Mapillary data usage on OSM 6 months ago

AFAIK, it's a tendency to use source=* on changesets, not on objects (that was the old habbit).

Sadly, overpass doesn't offer changeset-based queries, so that wont be possible. But I guess the real number is a lot bigger.