OpenStreetMap

Vincent de Phily has commented on the following diary entries

Post When Comment
4 826 424 "addr:country=DE" 12 days ago

@AndiG88

I'm not sure I follow the point in your 1st paragraph. My point is that when you want to route to a particular housenumber, the routing algorythm will find the closest matching way and direct you there. Most of the time, doing that matching using just the street name, even if there are multiple corresponding ways, is correct. But sometime (typically in housing estates) the name-matched osm way that is closest to the house is the wrong one. If matching using a relation instead, there's only one osm way to choose from and no mistake made.

Regarding the ease of contribution (for newbies and veterans), there is no obvious winner. Creating the relation is harder for newbies, same amount of work for veterans. Maintaining it is easyer for both.

It's also worth it to add a house to the associatedstreet relation even before you know its housenumber. Firstly because it makes surveying housenumbers easyer, secondly because it is usefull information even in the absence of housenumbers.

4 826 424 "addr:country=DE" 17 days ago

Let's run some actual data compression numbers :

  • download extract from geofabrik and decompress
  • use grep to filter out the addr:country tag into a new file
  • recompress both files

$ \ls -Sl brandenburg-latest.* -rw-r--r-- 1 work work 2019804582 Jun 24 00:34 brandenburg-latest.osm -rw-r--r-- 1 work work 2007110472 Jun 24 00:38 brandenburg-latest.nocountry.osm -rw-r--r-- 1 work work 159076860 Jun 24 00:34 brandenburg-latest.osm.bz2 -rw-r--r-- 1 work work 158989054 Jun 24 00:38 brandenburg-latest.nocountry.osm.bz2 -rw-r--r-- 1 work work 119848272 Jun 24 00:34 brandenburg-latest.osm.xz -rw-r--r-- 1 work work 119720968 Jun 24 00:38 brandenburg-latest.nocountry.osm.xz

The gain is 0.6% for plaintext, 0.05% for bzip2, 0.1% for xz... All in all not very impressive, but not as insignificant as the 40K that flohoff expected. Compressing a string disseminated in a file is not as easy a compressing a file made entirely of that string.

Also, remember that downloading and decompressing data might not be your bottleneck. Parsing the decompressed data has its cost.

Since the numbers are small (I could increase them by using an adress-focused extract, but why bother ?), I agree that size is not very important in this case. But it's still good to have proper numbers :)

4 826 424 "addr:country=DE" 17 days ago

I'm in the "no redundancy" camp, mainly because it is less time-consuming to create and maintain (from fixing a typo on a street name to the anexation of Crimea). The fact that the data is smaller and tidyer is a bonus. For the specific case of the associatedstreet relation, it also fixes the problem of finding the right street to park in front of a house when the nearest-matching-way algorythm fails.

Normalizing the data does make querying more complicated, but the fact is that relations offer advantages and/or make things possible that wouldn't be otherwise. They are used more and more. So if your tool doesn't handle relations... It doesn't handle OSM data very well at all. Go fix it.

If you "don't want a geodatabase" because querying street and country at runtime is too costly, add those tags to each object at import time.

There's a balance to be found between coders/computer ressources and data contributors. On that point, while it is probable that geocoding will eventually be computationally "solved and finished", adding and curating data will never be. So I lean on the data contributor's side in this equation.

Of course there are compromises to be made. "Don't tag to the renderer/geocoder" only goes so far, pragmatism is also needed. But in the addr:* case, I feel that this pragmatism is a bad idea.

Why doesnt my edictions are good to gpsyes and others?? 22 days ago

A quick search in help will give you a few similar answers on that topic.

JOSM tip for squaring buildings about 2 months ago

Alt+extrude will create a second store.

The building tool is great for simple things, but I find that it asumes too much (such as the value of the building tag or the angle of the next building) while not handling L/T-shaped buildings and leaving unshared nodes everywhere. Extrude is less advanced but more versatile.

JOSM tip for squaring buildings about 2 months ago

Thanks, didn't know about this one. For the given example I'd have used extrude instead anyway, but I can see other cases where it'll be usefull.

Hidden playgrounds 2 months ago

Thanks, you don't realize how important those are until you become a parent. Go map playgrounds ! :)

Targeting inappropriate 'layer' entries. 3 months ago

I suppose if you got confused while looking at them it means you were already in the process of fixing stuff in the area, so that would tick the "dont change them unless you're also changing other stuff as well" box.

The "this user did something weird, maybe he did other mistakes that I can correct" argument is valid, but only if you can actually find stuff to fix. If you're armchair-mapping and only fixing odd-but-correct tagging, you've removed the "something needs improving here" hint that other mappers, perhaps local ones, might have used to do more substantial improvements.

Just don't go hunting for unusual layer values if that's the only thing you're going to change. It's like contributing a whitespace-only commit to software code... Not very usefull. It may be good to take, but there are probably better uses of your time.

Just my opinion, not an instruction; don't listen to me if you reaaaly want to do those kinds of cleanups :p

Targeting inappropriate 'layer' entries. 3 months ago

While it is nicer to follow these best-practices (don't tag layer 0, tag short distances only, use 0 for bridges, etc), there is nothing fundamentally wrong with these weird layer values. A layer=-5 doesn't necessarily correspond to a tunnel or covered way. At worse, these cause data bloat. I wouldn't go fix that unless I'm also doing other (necessary) fixes in the area.

Verifier import cadastral 3 months ago

En région montagneuse les images satellite ont souvent un gros décallage, donc j'aurais plustot tendance à faire confiance au cadastre. Mais rien ne vaut un relevé GPS.

Panoramic views aka "Street View" on OSM? 3 months ago

There's http://mdl29.net/projets/open-street-view/ which got a bit of funding from french local touristic agencies. They have a bit of code for the viewer, but are also actively working on DIY hardware (using a phone has many drawbacks).

Progress isn't very speedy and they don't have a place to upload your own panos yet, but it's still a promising project that could do with some extra help.

Quelques réflexions autour des Notes 3 months ago

"On ne peut toujours pas trouver et afficher nos notes" http://www.openstreetmap.org/user/JBacc1/notes ne répond pas au problème ?

How do you map house numbers efficiently? 3 months ago

FWIW, I do not like tools like Keypadmapper because they create either a node or a GPX waypoint which isn't merged with the existing data. Your mockup saves on typing but suffers from the same problem.

My workflow for housenumbers is to first trace buildings from imagery, then survey and map using Vespucci. I do this while walking and rarely stop, so there are "holes" in my mapping that I fix afterwards in JOSM. If some geometry needs to be changed (for example a building that needs to be split in two), I add a fixme tag in Vespucci.

I'd welcome a reduction in the number of clicks in Vespucci, but I'm not sure your mockup would help : it seems too specialized (I often map POIs as well when I do housenumbers) and only addresses the typing of the actual number (BTW, what about bis/ter/etc ?), not getting to that stage. To me, typing numbers is less of an issue than needing 4 well-aimed clicks to be able to begin typing.

Crimea in OpenStreetMap 3 months ago

What is your process for displaying data that is (presumably) coming from OSM but using different boundaries ? Just a set of manually-edited polygons in an overlay, or something smarter ?

Seeing as there'll always be governments that do not agree with OSM's set of boundaries, it'd be nice if there was a howto to render custom borders.

Call to map Misery 4 months ago

There's plenty of blanks to fill too.

OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike 4 months ago

You're welcome to fork OSM data and relicense it as PD. Between contributors who won't agree to the relicense and imported data that cannot be relicensed as PD, you'll have to delete a lot of stuff before you can declare your data PD.

The share-alike question has been debated a lot already, but if you want to change the status quo today you'll need to put in a lot of energy.

Personally, I'd be very happy for Google (to pick a polarising example) to start using OSM data, but not if they can just take it and say "it's ours". Crowd-sourcing vs crowd-serfing. Without SA, It's also quite likely to be a one-time import that really doesn't benefit the osm data.

The SA requirement make it harder to use OSM data in some situations, but it doesn't make it impossible. Just don't merge datasets with incompatible licences, use them in parrallel instead.

We could certainly listen to people/governments who have PD data but don't want to put it in OSM because of workflow issues (there's no licensing issue for PD->ODBL). I think that maintaining/curating imported data is the main issue.

I also can't see how OSM would become irrelevant unless it drops SA. It's plenty relevant today, we've got more contributors than anybody, and we're growing fast. The future is bright, SA isn't slowing us down.

The first 30-day challenge: retrospective 4 months ago

Thanks for the retrospective :)

There's always that problem with OSM contests: people will start gaming the scoring algorythm at the detriment of contribution quality. This is especially true if you target the contest at relative newbies (as I assume most scouts are).

It's very hard to avoid that (it's human nature), and I imagine it's one of the reason why we don't see more contests (which are otherwise fun and positive). Maybe we should ditch automatic scoring altogether, and use a jury appreciation instead. But of course that a lot more work to organize.

Name suggestion support in editors 4 months ago

I like that, but I'm a bit worried that I won't notice when a completion is just for the current textbox, or will autofill other stuff as well. Can I choose between auto-filling just the current field or all the preset's fields ? Does undo work on the autofill, maybe spliting the action into 'autofill textbox' and 'autofill preset' ?

Another point is that the use-case for vespucci is very different from desktop editors. For example, I do mostly housenumbers and POIs in Vespucci, wereas my JOSM edits are more varied. It would be great if the completion index prioritised data from vespucci changesets, so that for example "addr:housenumber" comes up before "admin_level".

The wrong side of mapping transient events in OSM 4 months ago

Re "flags about the estimated live span of objects" we do have end_date along with other suggestions. But there is a fair amount of resistance to the idea, because of the risk of making a big mess (very few tools support the end_date tag, for starters), and many people would rather shove that data away to OpenHistoricalMap.

The wrong side of mapping transient events in OSM 4 months ago

I'd agree with you in this particular instance, but where do you put the limit on what is "transient" ? Something that disappears after 1 day ? week ? month ? year ? How certain must the end date be ? Roadworks come to mind as something that everybody will rate differently.

I'm playing the devil's advocate here, but I think that "I feel this feature is permanent enough to map" is likely to always win because bikesheding will ensure that "permanent enough" never gets a good definition.