Polyglot has commented on the following diary entries
|Mapillary-Straßenbahnmapping||4 days ago||
Nicht nur 'wegen' Nakaner. Es gibt auch Leute die ein cam unter ihren Sattel auf dem Fahrrad montieren. Für Mapillary ist das wichtigste das die guckrichtung richtig steht.
Ich meine es wäre noch etwas fremder wenn die Sequenzen umgedreht werden.
|Mapillary 1.0 for Android||3 months ago||
You found my diary entry before I was quite done with it :-) Usually I change it a few times when rereading. Anyway, glad you like it. I still feel a bit bad that it took 2 weeks to get started on it.
Also glad to hear you're working on that overexposure problem. Looking forward to help with testing that too :-)
|Busroutes in Brugge||3 months ago||
The data coming from De Lijn is refreshed 4 to 5 times per month, so I don't see how it can be outdated. Anyway, after the 'dispute' with Peeweeke I've mostly left Bruges alone. More recently I've been checking and updating all the itineraries all over Flanders region though. It would of course be better that somebody with actual local knowledge does this.
That's the reason for writing these and for creating some screencasts:
I hadn't realised I stepped on people's toes back when I was adding/updating those thousands of bus stops and I apologise for the inconvenience caused. When stops were already present, I conflated them manually, mostly keeping the positions from the original mapper. The stops with inaccurate positions were the ones which couldn't be placed based on the aerial imagery available. Each and every one of those stops has been checked manually, so it was certainly not a blind import.
I went digging in my mailbox. Apparently I resurrected a stop that wasn't served anymore for a line that changed. Since this was in 2014 it surprises me that the current data of De Lijn wasn't totally accurate at the time. When I hear about a change around here where I can check the ground truth, it's always accurate.
Anyway, I hope the work I did on the conversion of the data and the scripts can still help you to keep the lines up to date. It's all meant to make things easier, not harder.
The script to help with creating/updating the routes needs some more work to be really useful, but at the moment my interests are shifting toward Mapillary and their recognition of traffic signs, so I don't know when I'll continue to work on the itineraries or on the PT data.
|An idea for making it easier to link external data to OSM||3 months ago||
Euhm, osmdata.org doesn't seem to exist!
Concerning wikidata, there is also:
subject:wikidata that's who/what the statue or picture depicts architect:wikidata name:etymology:wikidata for streets or objects named after the wikidata item operator:wikidata=* brand:wikidata=* artist:wikidata=*
So it's rather versatile.
There is the issue of whether wikidata wants entries for, for example camp sites, but they want to include a lot more than just items noteworthy enough to deserve a wikipedia page, so normally that shouldn't be a problem.
It was indeed a bad move to refer from wikidata to OSM relations for named areas. I've been telling them that from the start. The only effect it had is that they didn't create more such properties, I believe.
What they also need on their side, is a way to use the OSM wikidata tag in a Wikipedia page, for example. Overpass is the ideal glue here. Unfortunately they deleted my attempts to create such links:
They kept this one: https://nl.wikipedia.org/wiki/Guido_Gezelle#Tastbare_gedenktekens
Anyway, I think wikidata can get us a long way towards the goal for permanent ids. For the items which really don't fit in their DB, we might still need other types of foreign keys. I'm curious how they would react if I'd start importing 50000 bus stops into wikidata, let alone those of the whole world, but I didn't ask, so maybe it'd be just fine. For the time being I'll keep using ref:OPERATOR=xyzxyz.
Also don't underestimate OSM contributors, we're generally quite an intelligent lot, able to decide whether something deserves to keep the same identifier or not. OTOH, it's also through that those external DBs will need to run Overpass queries to check whether all their identifiers are still present in OSM and if they should be on exactly 1 object only, they'll have to come over and repair occasional damage. At least they'll have a practical way of doing that.
What would be nice is editor support for the wikidata tag, though. Showing the identifier in the user's language and fall back if it isn't, instead of the Q-number.
|Address evolution in Belgium||4 months ago||
The addresses on nodes in the Brussels region can be explained by houses with more than 1 house number. Many houses on corners have 2 over there and ofc many have also been merged.
The data conversion was quite easy, as we started with high quality data, including building contours to booth. OTOH, I don't think a lot of checking has been done during the import phase.
Anyway, I only converted the data and added a few streets here and there. The import was executed by local contributors, as it should.
|Mapillary||4 months ago||
There are 2 reasons why Commons is not suitable for the kind of pictures I'm taking. On the one hand we need some very specific, but to most people quite odd 'details', like housenumbers, opening hours, collection times for mailboxes, bus stops, and whatnot. Taking pictures of that stuff, makes people look at you funny, upload such pictures to Commons will get you scolded at :-)
The reason why my 'whortwhile' pictures were deleted lies in Belgian law. We have no Freedom of Panorama in this country. Germany does and The Netherlands too to some degree, but here and in France we don't. I call the North and the East progressive and us and the South outdated... So all the pictures of artwork, where the artwork was the central theme can't be uploaded to Commons, unless one gets explicit permission from the author. It's not entirely trivial to get that permission, especially with people who willingly talk to you when you meet them in person and on the phone, but who prefer to not correspond by email.
So I don't think the situation can be helped. If I find particularly interesting picture of a plant or an insect, I'll upload it to Commons, but for most of the pictures I make, they're out.
I'm not sure how Mapillary works around this FOP rule. If you consider all those pictures as a collection, then the artwork in some of them is not the central theme, but if you consider each picture separately, some of the pictures I (and possibly others) submit will contain pictures of statues/paintings and other artwork. I read a bit about FOP in Sweden, and the conclusion I came to is that information panels are problematic over there, while artwork isn't.
I'm not a lawyer though and I never will be. All that dribble gives me a headache, so I'll just accept it if those pictures would be removed/hidden at some point.
|Mapillary in iD||4 months ago||
Please don't take it as a criticism of your work. It's great you did the integration. I'm merely commenting from my own perspective as a user. A newbie as far as iD goes, but an old hand as far as OSM editing goes (with both JOSM and Potlatch), which may not be how 'real' newbies perceive it.
Anyway, it's mostly criticism of how iD works. Not sure if I'll ever get comfortable with it. I'm really grateful for the work you did on it!
|Mapping public transport in Belgium||4 months ago||
On the one hand, it might. On the other hand it would Megan changing 70000 nodes once again. The scripts I'm developing depend on these tags, so they need to be changed wholesale. Doing it gradually would take ages and it wouln't be practical. I wasn't aware of this convention to add BE. I'll keep it in mind if I feel compelled to make a change to a large amount of them for other reasons. It's unlikely such need will arise during the next few months or even years, though.
|Mapillary||4 months ago||
By pointing to one representative picture, the person clicking through gets convenient access to several pictures + the surroundings.
I do think Mapillary deserves special consideration, as it's an open project like wikipedia and wikidata. The best thing we can do is make symbiosis among open projects as easy as possible.
You mention Google Streetview. Shame on you :-) As far as I know we didn't receive permission from Google to play with 'their' toys. Even though they are doing an extremely useful job of photographing the public space and they are nice enough to let the world have access to it. Hopefully one day they'll prove there more than merely 'not evil', as they claimed, but actually become nice on top of that. Until then, it's good to be able to fall back on and contribute to an open alternative. Of course, Google can never give more than a general view from where they can drive with their cars, so Mapillary will always have that little bit more by providing access to such places and much more for actually letting us use it as source material.
|Mapillary||4 months ago||
Thank you. That's great!
|Mapillary||4 months ago||
I'd love to see a proper plugin for JOSM to integrate mapillary in the workflow. The mapillary tag would rather be for a site like Openlinkmap.org, so it becomes possible to look around near the referred object or to view it from different angles, to get an idea what it is, without necessarily having to go there.
|Learn-a-tag: highway=escape||5 months ago||
I added links to 2 Youtube videos to our wiki page
and a link to Overpass Turbo on (https://nl.wikipedia.org/wiki/Noodstopstrook) and (https://en.wikipedia.org/wiki/Runaway_truck_ramp#See_also)
|Editing with Overpass and Level0||5 months ago||
Hehe, my first thought was also: mechanical edit. On the other hand, anything that helps mappers be more productive has my blessing.
I would probably have used Notepad++ to perform the search/replace as it supports regex (regular expressions; a very powerful way to work with text and morph it).
Thanks for looking into this. There is a good chance it will come in handy later on.
|GORDON'S ALIVE||7 months ago||
Frederik Ramm is on his way to add support for undelete in JOSM. He changed something to the API already during the latest Karlsruhe hackweekend.
I'm a complete JOSM convert now, but at some point I was using both Potlatch1/2 and JOSM alternatingly. Glad to see it got some improvements.
|What is the OpenStreetMap convention? Do we tag addresses on buildings or on separate nodes?||over 1 year ago||
Or an Address relation containing the building, an entrance=main node at the front door and a node where the mailbox is located? I almost forgot to add the parcel to it.
Polyglot (who would also be in favour of a node per address, but does it go inside the building outline, or as a node of the building outline where the front door is?)
|Daten für Cusco Peru||over 4 years ago||
Ich habe vor 2 Jahren viel daten 'surveyed' für Cusco,Urubamba,Quillabamba und Santa Teresa. Leider nur ein Jahr nachher eingetragen. Viele Strassen haben jetzt Namen und es sind sogar welche Hausnummern eingetragen von mir!
Viel Spass, ich werde leider nicht schnell neu ins Peru gehen.
|JOSM is driving me crazy||over 4 years ago||
Yep, that was the culprit. Many thanks for your help!!!