IMO, the main problem is with the amenity one. That category is just too broad, and many attempts have been done to get tags away from amenity=*

Apart from that, it’s indeed true that there are tags for physical stuff, tags for restrictions, tags for services, … But I don’t see a problem in that, as long that the keys are not too broad, so you know from the key if something is physical or not.

Other strange things include keys that are used mainly (or only) to represent ways and are in some cases used on nodes or on areas. Think of highway=traffic_lights, or waterway=riverbank.

But in any case, mechanical edits are not allowed for this purpose. So if you want to change something, you have to change all tools, all data users, and the entire community.

Do you also know the space between the stones?

Else, I would suggest a scripted method:

• Determine one corner of one stone with high precision, or maybe multiple corners to get a higher precision.
• Calculate a grid of possible corner points using the dimensions of the stones and spaces between the stones.
• Extract all corner points of those stones (f.e. via overpass), and round them all to their nearest position in the grid
• Upload it again.

Of course, the result has to be checked in JOSM before the upload.

This method would work best when you have a high-precision position available for the site, or for one of the stones. If you don’t have that position, you can still work from an estimated position. In that case, the relative distances would still be correct, and when an exact position is known, all stones can be shifted together.

C’est pas sur qu’il s’agit d’un erreur de la part d’OSM. Ça peut aussi être un erreur de la part de Be on Road. Et cette app seulement utilise les données d’OSM. L’interprétation des données et la calculation des routes est la responsabilité des apps.

Mais je ne sais pas de quelle carrefour il s’agit, donc ça peut être un erreur dans les données aussi.

(excusez-moi pour mon français limité, c’est pas ma langue maternelle).

This is why imports are considered bad in many cases, they don’t take maintenance into account. First of all, there’s no community build around it, secondly, the data structures are sometimes hideously complicated.

The multipolygon relation itself isn’t too great either, inner and outer have no meaning on a sphere, and you notice that when small mistakes cause those reversed inners. But it’s the best we have now.

If you really want to work with multipolygon relations of that size, you should use JOSM, use it to split the relation, and take out small forests again and again.

In the other case, I don’t think anyone should oppose just deleting a bad import, when manual quality is received in return.

It’s no problem, since my native language is Dutch, I can understand German (though it takes some time to get used to the spelling every time I start reading German). Writing is a lot more difficult, not only the spelling, but also the conjugations.

I must warn you, our tool is made specifically for the CRAB database, so it includes fields like the precision, and depends on an administrative boundary structure that would make it hard to port to other regions and databases. Though the idea of using overpass queries with client side comparison can of course be tested and evaluated.

You can always pm me.

Sorry to answer in English, but my German is really bad.

I think I tried to do more or less the same for the Flemish house numbers. See the tool we developed: http://crab-import.osm.be/import.html

Just enter a post code (I’m currently working in the post code 8800) and check to compare with osm data, and press update.

It compares the governmental data with osm data, and sees which addresses are not matching. At the bottom of the page, there’s a map with colour codes.

Though my approach is different in that I don’t use a central server (just a webpage hosted via github and some json files). The osm data comes live from overpass, and the actual comparison happens at the client (in js scripts).

The disadvantage is that it’s impossible to get a big picture (querying big areas is impossible with overpass, and comparison would time out too), and I also can’t keep statistics over the time (because we never get the results from the comparisons in the first place, and most municipalities won’t be queried for a long time). So the tool is pretty much worthless for statistics.

The big advantage is for the mapper though. As overpass normally only has a few minutes delay, just pressing update makes it possible to see all the new changes pretty much immediately.

When I started my project, I didn’t have an idea about this project, but I guess we can learn from each other. The tools have very different use cases for sure.

You mean minecraft? What makes you think they’re convertible in any way?

I see BIN (Belgian instead of Deutsch) has the same recommendations.

But BIN also requires small letters (b instead of B).

This is one of the most stupid recommendation I’ve ever seen. It makes it hard to parse in software, and isn’t needed at all to be readable. In contrary, capital letters are a lot easier to read, and spaces after numbers don’t matter a lot.

It becomes extremely irritating when bus numbers are added. Like “Bornstraat 48 a bus 5” vs “Bornstraat 48 bus 5”. That “a” just looks like a lost letter.

In this case, I just hope people will never start using the BIN/DIN norms.

Nice improvements.

What’s the usual data age in Scout? And in case it’s several days, would it be possible to mention the extraction date in the note?

Thanks a lot.

Just wondering, is it possible to go from the lower primary road into the tertiary road?

Because, given the current oneway restrictions, this isn’t possible on the map.

PmaiIkeey about your question of why it’s in French. Well, it’s not part of OSM, it’s build around OSM (like so many other tools).

And it just happens to be build by a French. However, it’s also available in English on that site: http://umap.openstreetmap.fr/en/ (which is in fact the link pnorman gave you)

1: The road types are a classification of importance (i.e. how many people use them).

Since the system originated in GB, it follows the names used there. Other legal differences (like maxspeed) are noted by using different tags or a different way of mapping.

In the case of dual carriageways, it has to be mapped as two parallel ways in both directions. That way, it becomes clear.

2: You shouldn’t split streets in arbitrary points. Certainly not to get different rendering. Instead, you can use higway=stop and highway=giveway nodes on the other roads. osm.wiki/Tag:highway%3Dgive_way

When the mapnik devs find it important to render names like this, they can always use these nodes.

3.1: The renderer needs some time to update. Certainly in the last days, as the rendering style changed a bit, and the servers had to render a lot of new tiles. So the waiting times were longer than normal.

That causes different zooms to show different ages of tiles. Just wait a bit to find it updated (the more you zoom out, the longer you’ll have to wait, as the more data it needs to process to make that tile).

3.2: If you know names of neighbourhoods or localities, you can map those. They can be interesting. However, these names are often hard to find, so they’re not mapped a lot.

3.3: That’s just a matter of time before you know the tags. War memorials are just like other memorials, so a search for “memorial” should bring you to the correct tag. And you can always use the search feature on the wiki to find the correct tags: osm.wiki/Main_Page (the wiki documents the tags you see in the advanced section of the editor)

3.4: When you select a way, you see the nodes (as circles), but you also see arrows in the middle of the segments to show the technical direction of the way (important for one-way streets f.e.). But that arrow has a dual function. If you hoover it, you’ll see a +-sign next to your mouse cursor. And when you drag the arrow, a new node will be created there.

I hope this is what you wanted.

3.5: That depends on your community and what you want to discuss or ask. There’s IRC (live chat): osm.wiki/Irc (use it for quick questions, or small discussions) There’s the help site: https://help.openstreetmap.org/ (use this to ask help, not to discuss stuff) You can also subscribe to a mailing list: osm.wiki/Mailing_Lists (most veteran OSM users are subscribed to multiple mailing lists) There are also forums: http://forum.openstreetmap.org/ (not all communities are active on the forum, check if there are people before you ask or discuss something) And the wiki is mainly for documentation (of tags and tools), it isn’t used a lot for discussion, and certainly not to ask help.

Some of these services indeed require separate accounts, but that’s just a result of history.

4.1: No idea what you mean here. But the OSM main page isn’t the only one offering OSM data for display. OSM offers the data, and others are supposed to work with it (make search engines, navigation devices, renderings, …). The things you find on the main page are just examples of what can be done, and they serve to attract new mappers and data users.

On the wiki, you can find a lot of smartphone apps and websites using OSM in clever ways (s.a. umap mentioned by pnorman).

4.2: I think umap is indeed the way to go. Though it’s still under development.

The tagging mailing list is indeed a pain because most of all, we can’t change the tagging when we want: If a tag is in use, no matter how bad it is, it’s the “used” variant, will be documented so on the wiki, and will keep to be used. The tools (like mapnik) will also only accept the tags that appear often in the DB, and thus ignore the new ones.

So actually, proposing a tag (and letting everyone use it), requires patching all tools that use the data, and lobbying to get the patch in.

The tagging mailing list should only aim to give guidance about using tags. Point out what should be done better (to get some consistency), or why a feature shouldn’t be mapped (we should only map stable, geographic data).

Anyway, for imports, or mass edits, it’s different. Those need to be discussed before they’re executed, because a bad import can ruin the hard work of many individual editors. And even a good import can be counter-productive when there’s no community behind it to maintain the data (and only lack of data creates a solid community).

It’s geographic data “the price of a coffee on a certain place”, but I agree it will be outdated way too soon (I wouldn’t be able to maintain the pubs in my village).

Next to that, there seems to be no standard currency notation. I’ve seen

• coffee:price = EUR3 (strange notation, I’d expect “3 EUR” in this case)
• coffee:price = £ 1.00 (ok, the app should read special signs. What sort of symbols are used?)
• coffee:price = $1.84 (now, it reads special signs, but there are many dollars. Which one is meant?)
• coffee:price = 1.10 (I should just guess the currency here?)

And Zverik is also right of course. What’s the price of a coffee at Starbucks?

Not sure what you want. If you want directions, you should check map.project-osrm.org

If you mean something else, you should explain it more clearly.

If it’s rather stable, and veryfiable, it’s worth to map.

So AFAIK, reefs belong to that category.

All it takes is someone with the knowledge about the possible classifications, and with the time to document it.

You can document your tag as a proposal: osm.wiki/Proposed_features But you can start using it, even before the proposal is accepted (be sure that you map only from data that’s legal to use).

+1

Le Nord doit recevoir plus d’amour.

Buildings are the result of a creative work by the architect. And a building plan might either be a copy of that work, or a measurement of the actual building. In the second case, it can be considered a database, and it costed a substantial amount of work to make.

So you certainly can’t assume that it’s legally ok to do without more legal research.

Otoh, it doesn’t mean you can’t use OSM. You could make your maps with JOSM, just don’t upload it to OSM yet.

Since you can use OSM for private use without the share-alike requirement. And educational stuff falls often under private use.

So you’re at least saved for your work. But you won’t be able to commercialize the app with the data you added (unless you get the subtleties researched).

Your research is highly welcomed though, and it might stimulate indoor mapping.

I mapped about all housenumbers as far as my dog could walk.

Though, since I live in a rather rural place, that ain’t so much.

It becomes harder when you have to walk (or ride) a longer way before you can start to map.

That’s why I think an import is good. But people should restrict themselves to places where they’ve been before. So they don’t import total rubbish.

And we should certainly have tools ready to find differences between OSM and CRAB. So we can find issues in both databases.

If you’re still not seeing the changes, this is probably related to your browser cache.

Normally, browsers keep the map images for some days, so that browsing goes faster. But when an image is updated on the server, it may be possible you still see the old image on your computer.

Try clearing your browser cache to see the latest renderings.

But indeed, you added the museum correctly (though I’d suggest to move the website to a “website” tag instead of “source”).