Sanderd17 has commented on the following diary entries
|Holistic/esoteric centers||about 22 hours ago||
It's not a simple question indeed. Thinking about tags is thinking about categorizing, which requires you to look into the problem first.
Some of those things you mentioned fall under healthcare. The difference with traditional healthcare is more in the research. Treatments developed by recognised healthcare researchers (like universities) normally do more rigorous and peer-reviewed studies. While the alternative healthcare might also work, but that is often disputed due to the lack of research, our due to non-conclusive research. Alternative healthcare typically doesn't deny existing healthcare, but offers additional, unproven, treatments. For this group, healthcare=alternative must work good enough (perhaps with some sub-tags to clarify the use further).
For the other things (f.e. cartomancy), it gets interesting when you read things about magic (f.e. on Wikipedia). You'll see that the line between magic and religion is small, and there are many definitions about it. Both have rituals and symbols, and both claim that theoretically impossible things can happen. However, IMO, the most clean distinction is that magic is demanding something, while religion requests something. F.e. a witch casting a spell to help you is magic. It's the witch that has the power, and if the spell fails, it's because the witch didn't do it well. While a priest can pray to help you, but that's only a request which God can deny. Given the similarity, maybe a similar tag should be chosen. F.e. amenity=place_of_magic. Together with some sub-keys, this might work fine.
|First Contribution to HOT - Iraq Missing Maps||5 days ago||
Thanks for your contributions.
About the distinction between primary, secondary and tertiary, that classification can't be decided on the looks of the road, but it needs a broader view to classify it. The difference mainly comes from the difference in importance. Primary roads connect all big cities, secondary roads connect smaller cities and towns, and tertiary roads connect villages to a city or town.
In places where unpaved roads are common, you also shouldn't just use "track" for any unpaved road. A track is a road for mainly agricultural use. If a road to a village is unpaved, its classification should still at least be unclassified.
So after all, it's hard to get the classification right when working on a single tile. The most important thing is to trace the roads, so the network becomes visible on the map, and the roads can be re-classified in function of the complete network. Osm is mostly an iterative process anyway.
About those U.N. maps, no, you can't use them without special permission. The U.N. often gets the maps or data from national or local governments, but that means the local copyrights apply. And in many cases, it's very hard to figure out if it's possible to use our not. In most cases, it's better to look out for US army topo maps. Those are normally more detailed (even if they're older), and are always legal to use (everything the US federal government makes falls under PD).
|It's elegant they said. It will be eaiser to change street names they said.||7 days ago||
I don't like AS relations, but for other reasons.
First of all, it's not clear what an associated street is. Is the street still associated when it crosses a municipality border, or when different parts get different postcodes? Do cycle lanes belong to it? And what about driveways? That relation is trying to bring structure to something that doesn't have a unified structure on it.
Secondly, it makes "upgrading" addresses from points to buildings hard. When only tags are used, it's quite simple to copy the tags from the node to the building, and erase the node. When relations are used, there are more actions needed. You still need the copy operation to bring over the house number (and perhaps other tags s.a. shops or amenities), but you also need additional work to search for the right relation in the list (which can become a long list), and add your building to it.
|The order/thinking/philosphy/system of OSM tags?||17 days ago||
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.
|untrue size of Berlin's Memorial of Europe's murdered Jews||21 days ago||
Do you also know the space between the stones?
Else, I would suggest a scripted method:
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.
|Erreur de donnée(navigation)||21 days ago||
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).
|CLC06 Import Cleanup||26 days ago||
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.
|Zeit für eine neue Hausnummerauswertung?||about 1 month ago||
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.
|Zeit für eine neue Hausnummerauswertung?||about 1 month ago||
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.
|from osm to mca extension||about 1 month ago||
You mean minecraft? What makes you think they're convertible in any way?
|Format der Hausnummern mit Zusatz (z.B. Musterstraße 1b)||about 2 months ago||
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.
|Now Live: Notes Posted By Scout Users||about 2 months ago||
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.
|Treino||about 2 months ago||
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.
|OSM issues apparently ?||2 months ago||
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)
|OSM issues apparently ?||2 months ago||
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. http://wiki.openstreetmap.org/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: http://wiki.openstreetmap.org/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): http://wiki.openstreetmap.org/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: http://wiki.openstreetmap.org/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.
|How to improve OSM: kill the bureaucracy||2 months ago||
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).
|COFFEEDEX & the single-tag revolution||2 months ago||
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
And Zverik is also right of course. What's the price of a coffee at Starbucks?
|Headway from NY to SF||2 months ago||
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.
|reef=?||2 months ago||
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: https://wiki.openstreetmap.org/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).
|La Communauté Urbaine de Dunkerque entièrement intégrée au BANO||3 months ago||
Le Nord doit recevoir plus d'amour.