1. normally, boundary ways are split on every boundary joint. So the boundary of france consists out of little pieces of boundaries between French and other municipalities. If these little boundary pieces still have more than 2000 nodes, there’s a problem with it.

2. The Josm Utils2 Plugin has some tools that can be useful, like “make multipolygon” to extract tags from a way to a multipolygin relation, or replace geometry (to merge two ways).

But afaik, transforming an SHP into OSM data isn’t the most difficult. The most difficult is doing the quality checks before uploading, and making sure that the data is blended in nicely with the existing OSM data (connects to neighbouring boundaries, etc). For this, you should really follow the import guidelines: osm.wiki/Import/Guidelines

It looks like nobody ever created that boundary. No idea why.

If you plan to include Belgium, you’ll see very strange stuff. We’ve had someone mapping lots of landuse, but mostly just aiming to reproduce the colour on mapnik.

He has drawn forest areas around single treetops (resulting in 300+ forests in a town of only 80000 inhabitants), and also making really bad mistakes like this one: osm.org/way/89503452

But mostly just wrongly tagging meadows and parks as landuse=grass. Like osm.org/way/298526045

I tried fixing it in the past, but just ended up frustrated.

Hmm, ice cream vendors aren’t real shops. Some offer places to sit, and in any case, you’re supposed to consume it rather quickly (unlike typical shops where you take the goods home before using them).

So I can see why amenity is preferred over shop in this case.

But mapping those is a bit tricky though. At least in Belgium, many ice cream vendors become waffle vendors during the winter months, or combine the two through the year.

amenity=waffle … sounds like a nice tag :D

Anyway, I’ll now shut my waffle.

It would probably be more interesting to see POI density used in some way. Like POI per area unit, or POI per population.

Many cities have different boundaries that would yield different results. Like in the case of Brussels, there’s the municipality Brussels (aka Brussels city), and the Brussels-Capital Region. But about the entire Brussels-Capital Region grew together into one big city.

Brussels city has only about 170,000 inhabitants, but with an area of just 33 km², that’s about 5300 inh/km². Brussels Capital Region has 1,160,000 inhabitants, with an area of 161 km², which makes 7200 inh/km². So even though Brussels city is considered the city, it’s clear that the entire region is in fact the city, and selecting one of the two will make a difference in the measurements.

When counting the POI, Brussels city has 2627 POI (http://overpass-turbo.eu/s/bC4) and Brussels-Capital Region has 11491 (http://overpass-turbo.eu/s/bC6). That’s of course a serious difference. But Brussels city has 0.015 POI/inh, while Brussels-Capital has 0.009 POI/inh, and Brussels city has 80 POI/km², while Brussels-Capital has 71 POI/km².

So in both cases, I’d call Brussels city to be mapped better than the surrounding region, although in absolute number of POI, Brussels city has a lot less. I think it would be a lot more interesting to compare these POI densities rather than the absolute numbers.

I’ll try to answer in German below, but my German isn’t really good enough for that. Hope you understand it.

The GPX feature of OSM is made to gather real GPS data in order to improve the map, it’s not meant to publish data exported from some app (possibly based on copyrighted maps). So there are certain requirements for the GPX tracks. One of these requirements is that every point should have a timestamp. Having a timestamp makes it more likely that the track is real, instead of exported.

Die GPX Merkmal OSM ist um echte GPS-Daten zu sammeln und die Karte zu verbessern, ist es nicht gemeint um Daten zu veröffentlichen die von einem gewissen App exportiert sind (möglicherweise auf urheberrechtlich geschützte Karten basiert). So gibt es bestimmte Anforderungen an die GPX-Tracks. Eine dieser Anforderungen ist, dass jeder Punkt einen Zeitstempel sollte haben. Einem Zeitstempel macht es wahrscheinlicher dass die Strecke wirklich ist, statt exportiert.

It’s easy to convert a list of node ids into an overpass query to query the actual tags: http://overpass-turbo.eu/s/bwx (the actual json is under the data tab).

I did it with some search-and-replace operations, but you could also have a script that reads your geojson and just outputs an overpass query. As overpass can’t count tags (yet), it’s not possible to use overpass to get your original list of ids AFAICS.

This shouldn’t be done inside the OSM database, but osm editors should make sure this doesn’t happen (by showing a warning when there’s such a node f.e.).

Also, wrt your example, it depends on how you measure angles. To take an extreme example, if you have a straight line from London to Beijing, the shortest distance is through Finland, and not through central Europe. So if you have a centre point somewhere in Ukraine, it might be a zero-angle point on a Mercator map, but it won’t be a zero-angle point when using exact shortest-distance lines. This effect also always play up on shorter lines, so every point in the database will be a non-zero angle according to some projection and a certain precision.

Btw, many data consumers already use the Douglas-Peucker algorithm to remove any points up to a certain precision when processing it. Like OsmAnd compiles their obf files while applying Douglas-Peucker in order to shrink the files.

When I got my first android smartphone, it had a GPS, but mobile internet was slow and expensive. So I bumped into MapDroyd (osm.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

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.

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

1. A city is usually no problem. As mentioned in the introduction ( osm.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.

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.

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. osm.org/#map=16/50.7190/2.8334), depending on how it’s mapped, and how you calculate intersections, this will return different results.

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.

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.

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.

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).

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.

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.