OpenStreetMap

Sanderd17 has commented on the following diary entries

Post When Comment
Some Important Questions for YouthMappers Trainer (From my Experienced) 4 months ago

Just a note, OSM data is licensed under the ODBL license now, not CC-BY-Sa: http://www.openstreetmap.org/copyright

Learning the OSM Way 4 months ago

Amenity=* tags should go on what they define. Around here, most schools have multiple buildings, and the playground is clearly part of the school. So the amenity=* tag defines the perimeter and not the building.

The same holds for other big features like industrial sites. If you can accurately define a feature with a single building (like pubs and restaurants in most cases), it's fine or even preferred to put the tag on the building.

Up-to-date open data imagery - it is available, use it! 5 months ago

This looks like great imagery for remote areas ... however, most people use maps in crowded areas, and most people also map in crowded areas.

So I wonder how useful this is for OSM as a whole. In contrast to some high-res, recent and accurate imagery of a small crowded area we might get by lobbying some (local) governments.

Why local assumptions are wrong for an international project 7 months ago

I read the documentation, but the documentation changed while I was using it ...

http://overpass-turbo.eu/s/fSN

Nonsense values of shop= key 8 months ago

Thanks for saying my opinion is irrelevant. But I say that the current schema works very well.

First of all, you're mentioning the big number of different shops. And then you're nitpicking on some of the most used values. I know people who complain about the amount of different tags they need to parse, and I know people who complain about the lack of values to describe a feature. I've never met someone who complains about both at the same time.

The shop=* works good. I can perfectly see if something is a supermarket, a bakery, a clothes shop or whatever. If it's some exotic shop, I just invent some tag for the shop, and it gets parsed by most tools as just being "a shop". That's perfectly reasonable.

Next to that, there's no problem with having local definitions for values. I live in Belgium, and I know perfectly well what a supermarket or a convenience store is (we don't use kiosk or mall very often). And so do all users in Belgium. So it doesn't matter that our definition is somewhat different to other definitions. People here will want a supermarket to the local definition, and find one.

But as the almighty intelligence ofc already knows, tags don't change in OSM because someone things some tag is better. Tags change because they are being used by a growing group of users. I wish you good luck with changing the shop tags.

POI help! 8 months ago

Try Overpass API (via the Overpass Turbo interface): http://overpass-turbo.eu/

See this to learn the syntax: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL ,

Or just use the "Wizard" to search features in a certain area.

African Roads and a Western Bias in Mapping 9 months ago

HOT tries to promote this classification: https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

Is there possibility to retag addr:housenumbers without european scheme? (updated) 9 months ago

Hmm, looks like Nominatim got a fix recently. At least last year, those queries wouldn't work at all.

I understand that there are differences between the numbering schemas, but they are so minimal that data users shouldn't treat them separately in most cases. Korea and Japan on the other hand use completely different addressing schemas (per block instead of per street), so they would need to be treated differently by data users.

For the NA vs EU case, an editor may indeed use that information to propose next numbers, but that's something very specific IMO.

Is there possibility to retag addr:housenumbers without european scheme? (updated) 9 months ago

Ugh, sorry for the double post. I got a HTTP error on the first try, and though it wasn't processed. Both posts are exactly the same.

Is there possibility to retag addr:housenumbers without european scheme? (updated) 9 months ago

Improperly tagged objects are indeed a problem. Like (AFAIK), Japan doesn't use streetnames, but block numbers. Those should be tagged differently than our addresses.

But I still don't get in what way you would process NA housenumbers differently from European housenumbers. A housenumber is bound to an OSM object, which is bound to a location. That's all you need to know to guide you to an address.

In Europe, there's also no way to estimate how far a certain number is in the street. Like just for my street (I don't have to look far), number 28 is 440m from the start of the street. But number 29 is 1400m from the start. So there's 1km distance between 28 and 29. And the longer the streets, the bigger the differences grow.

And yes, we don't have 5-digit numbers, but in what way would that make a difference for data users? Housenumbers can only be processed as string, strings that you can place in an address. Is there any tool using addresses with OSM data that has problems with 5-digit housenumbers? (OsmAnd, Nominatim, ...?)

In contrast, let me show you some European numbers (only from my own country actually) that Nominatim can't handle because it doesn't bind to streets cleanly.

http://osm.org/way/158656523 http://osm.org/way/311932649 http://osm.org/way/257712423

Especially Nominatim has problems with the above addresses.

And here some very special streetname (though no addresses mapped yet): http://osm.org/way/30126046

Is there possibility to retag addr:housenumbers without european scheme? (updated) 9 months ago

Improperly tagged objects are indeed a problem. Like (AFAIK), Japan doesn't use streetnames, but block numbers. Those should be tagged differently than our addresses.

But I still don't get in what way you would process NA housenumbers differently from European housenumbers. A housenumber is bound to an OSM object, which is bound to a location. That's all you need to know to guide you to an address.

In Europe, there's also no way to estimate how far a certain number is in the street. Like just for my street (I don't have to look far), number 28 is 440m from the start of the street. But number 29 is 1400m from the start. So there's 1km distance between 28 and 29. And the longer the streets, the bigger the differences grow.

And yes, we don't have 5-digit numbers, but in what way would that make a difference for data users? Housenumbers can only be processed as string, strings that you can place in an address. Is there any tool using addresses with OSM data that has problems with 5-digit housenumbers? (OsmAnd, Nominatim, ...?)

In contrast, let me show you some European numbers (only from my own country actually) that Nominatim can't handle because it doesn't bind to streets cleanly.

http://osm.org/way/158656523 http://osm.org/way/311932649 http://osm.org/way/257712423

Especially Nominatim has problems with the above addresses.

And here some very special streetname (though no addresses mapped yet): http://osm.org/way/30126046

Is there possibility to retag addr:housenumbers without european scheme? (updated) 9 months ago

Europe also has some distance based numbers. You mention Portugal, but I know several villages in France that also use that schema.

Then there are also streets where numbers take "jumps" on crossings. Not often by 100, but rounding up to the nearest multiple of 10 happens sometimes (note that in taginfo, the numbers 10, 20, 30 are also everytime more popular than 9, 19, 29, which shows my point).

Then we also have things like bis-numbers. Where houses are build between adjecent numbers (f.e. new houses between 29 and 31), and the number gets an extra letter (29A, 29B, 29C, ...).

Housenumbers in Europe are far from uniform. and I really see no reason why the US addressing should be handled that much differently. There are small differences between countries. And yes, starting with 6200 isn't something I've seen before in Europe. But I doubt it's different enough to need a new schema.

Volunteered Geographic Information … why, that's us! 10 months ago

(and also section 8)

Volunteered Geographic Information … why, that's us! 10 months ago

OSM is also protected by intellectual rights, just like commercial data is. The only difference is that we use intellectual rights to force a rather free license on the users of the data.

But one of those terms in the license (which anyone is required to agree upon when using the data), is that OSM isn't liable for mistakes in the data.

See http://opendatacommons.org/licenses/odbl/1.0/ (point 7.1).

So I see absolutely no difference with other providers.

Day 7, Exploring new tools. 10 months ago

Keepright is more specialised in technical mistakes (misspelled tags, wrong geometry, ...), while this tool allows you to inspect some thematic data.

It allows you to see all boundaries, all addresses or all waterways f.e. and check which ones are missing and how they are tagged.

It's a great tool, but only useful for the themes offered.

Starting around my local area 10 months ago

Hi winnieryan,

The original data in the USA mostly comes from the free governmental TIGER dataset. This dataset had a basic road layout, but overall a low quality with lots of problems.

Other data (churches, post offices, ...) are normally added by volunteers (like you now).

If everyone maps his own house (or street), the entire world will be mapped.

PS. If you want to see what an active mapping community can do, take a look at Germany (Bremen f.e.: http://osm.org/#map=17/53.07758/8.80584 ), in Germany, governmental data isn't free, so everything you see is made by volunteers. I hope that a look at a well-mapped place inspires you to see what can be done.

Mapping Andhra University College of Engineering (Andhra Pradesh, India) using Field Papers: 10 months ago

Something not yet mentioned: you have some ways with only a name tag. F.e. http://www.openstreetmap.org/way/393931858

This won't show up in any renderer or other data user, instead you should try to describe the feature with tags (f.e. http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dplayground in this case).

And as mentioned by MarkusHD, names are for named features, so the name should be removed from that way.

Then, there are of course the buildings that should have straight corners (as mentioned before), but you also seem to follow building roofs. When imagery is taken at a non-straight angle (which depends on where the plane actually flew), then the imagery is georeferenced against the ground height. So only the ground floor of the building will be more or less correct, and the roof won't.

That said, I'm glad you started working on a local piece of map. That's the ideal way to learn mapping. When you have perfected this piece of ground, you will know a lot more to start doing typical mapbox work.

As you can't see the complete ground level, the best method is to draw around the roof, and then drag the building so it matches the ground floor.

Idea of issue tracker for tagging scheme 11 months ago

There's a big difference between software bugs (and even feature requests) and OSM tags.

Software is normally managed by a select group, they choose whether they want a feature or not, and whether a solution is good enough to solve a bug or implement a feature.

OSM tags on the other hand are more of an anarchy. Everyone can introduce new tags without any approval from others. In that anarchy, some tags grow naturally, and become a standard. Tools start using them, mappers see examples from other similar features, and the tag becomes more popular.

So introducing a new tag is, more than anything else, bootstrapping that positive-feedback loop. The well known wiki proposal process is just a part in bootstrapping that loop, by making the tag known and getting rid of any controversy around it.

So I don't believe bug reports will do anything except introducing yet another channel to discuss stuff and spread communication even more.

There are other things that could be done though, like helping tools to implement tags. Examples include: * creating a set of default tag implications. Like highway=residential inside the boundaries of Belgium implies maxspeed=50 * Making natural language translations of tags. Like admin_level=8 in Belgium can be translated to "Gemeente" in Dutch. * Adding categories to tags. Like amenity=pub belongs in the "food and drinks" category. * ...

By having data like that in a uniform format, tools can parse it directly, and it would help a lot with the creation of new tags IMO. By empowering tools, people will also start using these standardised tags more. And a project like this could be managed in a more centralised way, with a bug tracker and a team that decides which additions are good and which aren't.

Mapping private subdivision roads and other gated roads 11 months ago

Where did you get the fee thing for access=permissive? AFAICS, access=permissive means it's owned by a private person or company, but the owner allows free traffic over the way (so no fee situation is no different from public roads, though they could theoretically as a toll, just like public roads).

In general, routers should know, if your start or end point is near a road with access=destination, access=private or any of those partial access tags, it's because you're already there, or you need to get there (and will take care of getting legal access). So the routers should be able to route you over those roads without problem, but they can't route you through.

When you tag the barrier, how would routers know if you can pass the barrier? There's no difference between a bollard to prevent through-traffic in a suburb road, or a bollard before a private road (f.e. an emergency road). Both could also be removable by authorised people (emergency operators, inhabitants, ...), so tagged with some other access tag than access=no.

I know that routers have difficulties with this (they usually just have passable or not passable road classes, and nothing in-between), but this isn't a reason to tag it differently. It's a reason to improve the routers out there.

Moreover, you're now making the access tags invisible (it's easy to render access tags on roads, while it's hard to render them on a barrier node), and the only reason it works now is because most routers still don't understand how access-tagged barriers work and just ignore them.

One extra argument: it's not because something is legally classified as having a certain access, that there's also a barrier enforcing that access. We have many streets that are marked as access=destination by a sign, but have no barrier whatsoever.

I do believe in a local tag creation process (we don't know how streets look like in the Philippines), but I think this way of tagging will seriously harm the OSM data consistency, and will make the job for routers a lot harder.

Natural language vs. abstract tags 11 months ago

Very interesting post. I'm from Belgium, so not a native English speaker, but close enough to England to share a lot of the culture.

We personally have no problem with kiosks at all. But we do have problems with other tags, mostly the range between amenity=restaurant and amenity=pub.

In our language, a "café" is where you drink beer, so that's a pub. Then we have "taverne", "tearoom" and "brasserie", which is more to visit in the afternoon, so more like a "cafe" in OSM terms.

Distinguishing between our fast_food and restaurants is also hard. Certainly when it comes to our "fritures" ( https://en.wikipedia.org/wiki/Friture ). A friture is a place where mostly fries and fried snacks are served. Ranging from take-away to having full service. However, they're not restaurants, as you need a license to have a restaurant title in Belgium. And IMO, it's very inappropriate to describe those fritures with full service as a fast_food amenity.

So we would like to introduce our custom tag amenity=friture, but nobody wants to tag objects like that, as it would remove all fritures from the visible map (while they are important, every Belgian village has at least one friture). And we can't get amenity=friture to render in mapnik before it gets used.

Some of the tags you mention also don't matter a lot. Like building=*, if you don't understand the tag, it's just a building, and doesn't matter which type. Most buildings are "yes" anyway.