Recent diary entries
Here the email I just sent to Scout/Skobbler:
I've had a look at Scout Signs. I agree that this is a comfortable way to collect maxspeed data. What I've compared in my region leads me to the following conclusions:
- the average Scout Sign I verified is misplaced by averagely 20 m¹
- all of the speed limits shown by Scout Sign I verified were already
mapped in OSM
–> I'd find it helpful to only show signs in JOSM for highways without maxspeed=* or maxspeed:forward/backward or where the by Scout collected maxspeed doesn't match the one on the highway
–> because: after closing a lot of Scout Signs with "it is already in OSM since 1-4 years" the task gets boring
- the OCR seems not to be failsafe: (Sign ID 25587, here)
I would welcome if discussions regarding this plugin would happen in the public, but regrettably there is neither a page for the plugin in the OSM Wiki nor is it mentioned there nor is there the possibility to discuss it at the place where you introduce the plugin.
Additionally it would be very useful to provide a link with the plugin to be able to learn just something about it. Scout Signs is one of only some plugins not providing any additional informations on plugin list:
(I sent a second email with this content):
PS: the following would enhance the workflow and usability, too:
- ability to click on the Scout Signs from the acitve data layer (atm one has to switch to the Scout Sign layer to can do that)
- hide solved/invalid Scout Signs (or at least show them in a different style)
¹ Examples where I could measure the offset:
A note to self but may also be helpful for other mappers.
Edit: The newer easy undelete of several ways may prove faster results with less work.
Recently I had to undelete a lot of stuff. I used JOSM with enabled remote control, the Plugins todo and reverter on Linux and established this workflow:
Find a changeset which looks a bit fishy. For example if the user seems quite inexperienced (short time OSM member, small amount of changesets) and has a lot of deleted objects on a changeset this seems worth a second look. Example-Changeset, deleted objects are shown like this¹:
Revert that changeset locally in JOSM using the revert plugin: press ctrl-t, enter the changeset number and click "revert"
Since we don't want to revert the whole changeset – maybe there are some useful edits in it, too – we need to take some extra steps:
- While JOSM is reverting which may need some time copy all the deleted ways from the changeset page into a file named w and remove all white spaces. Do the same for deleted nodes with a file n.
- Select all deleted ways using the remote control by running this command on a CLI:
wget -q http://localhost:8111/load_object?objects=$(for i in $(less file_named_w); do echo w"$i"|cut -d , -f1; done|tr "\n" ","|sed 's/.$//') -O -
- Add these ways to the todo list
Look at them one by one. You may also create a new data layer and have a look what the data of the place now looks like. You can also load the data in the layer with the reverted changeset which shows you how it will look after uploading but maybe confuses a little when loading too much data.
If undeleting the way would enhance the quality of OSM, add the tag tmp=keep to the way.
After going through all the ways take care for the nodes and select them like the ways before:
wget -q http://localhost:8111/load_object?objects=$(for i in $(less file_named_n); do echo n"$i"|cut -d , -f1; done|tr "\n" ","|sed 's/.$//') -O -
Since do only want to look at more valuable nodes (with tags on them) we drop all the others from the selection by using the JOSM search:
- press ctrl-f
- select "remove from selection"
query for type:node untagged
Add them to the todo list and check if they are worth keeping as you did with the ways.
Upload the selected data:
- Search for "tmp=keep"
- remove "tmp=keep"
- do "Upload Selection" (or press ctrl-alt-shift-u)
Optional: let the changeset remain open, download the region where you uploaded the undeletions, check for errors, fix them and upload. Close the Changeset with ctrl-alt-Q.
I am aware that there are more sophisticated ways to achieve what I did using the workflow above. I'd be glad if you would share them. :)
¹ As for now the markdown implementation is not able to show a strike through so I have to stick with a screenshot.
revenue with month of generation (pay-out two months later)
A small summary
Matching the end-of-year rallies for donations of a lot of institutions I want to have my little share in pointing the people to OpenStreetMap as receiver.
In 2011 I set up an affiliate account for OSM at Amazon.de. Since then a lot of people used the affiliate link to buy their stuff –4315 products– at Amazon so that we had a steady flow of averagely 140 EUR per month. Now for the headline I used: In this very month the 6000 EUR mark will be hit. With the beginning of the new year OSM will have received in total 6.021,25EUR. All numbers in full detail you find at the wiki.
In the name of OpenStreetMap I want to thank everybody who contributed to this sum. Of course I also want to encourage you to continue doing so! ;)
Have some relaxed holidays –
Affiliate mit Monat der Erzeugung (Auszahlung 2 Monate später)
Ein kleiner Rückblick
Passend zu den Jahresend-Spendenmarathons aller möglichen Institutionen möchte ich meinen kleinen Teil dazu beitragen, auf OpenStreetMap als Empfänger hinzuweisen.
2011 richtete ich für OSM einen Werbepartner-Account bei Amazon ein. Seitdem haben eine Menge Leute den dazugehörigen Affiliate-Link verwendet, um bei Amazon 4315 Produkte einzukaufen, so dass durchschnittlich 140 EUR pro Monat zustande kamen.
Nun zur Überschrift: In diesem Monat wird die Summe der Auszahlungen die 6000-EUR-Marke überschreiten. Insgesamt wird Amazon zum Jahreswechsel 6.021,25 EUR an OSM überwiesen haben. Detaillierte Zahlen finden sich im Wiki.
Im Namen von OpenStreetMap möchte ich jedem danken, der zu dieser Summe beitrug. Natürlich möchte ich dazu ermuntern, das auch weiterhin zu tun.
Entspannte Feiertage wünschend –
During four weeks of which I hiked about three I used mapillary as described in a previous blog post.
The result were 113.384 pictures with 596 GB size (on ext4 – on exfat it was 623 GB).
The maximum of pictures recorded during a day was 9000, the average per day 4500.
After review 101.261 pictures with 561 GB size (ext4) remained.
Hardware used (lent from the Mapillary company):
- 2x 128 GB microSD card
- 2x deltaco Powerbank 10 Ah
- 2x short cables USB-A–µUSB- ~20 cm
- 1x long cable USB-A–µUSB- ~100 cm
- 1x Sony Xperia Z1 Compact (w/o SIM card)
- 1x external 2,5" USB 3.0 drive 2TB
- 1x OTG-Ycable (purchased on my own)
- Anker 40W charging station (Amazon OSM affiliate link) with 5xUSB with 2A output each. My property, can really recommend it.
As of today I finally sent all the stuff back to Mapillary including the images which they will add to the database on-site. I'd need about 90 days to upload them…
On the way
I used the phone with the app blindly: Start the app and start recording, put it front-to-back inside a phone cover which gets attached to the left shoulder strap of the backpack. One of the Powerbank batteries I put into the lid of the backpack, attached the long USB-A–µUSB to it and fastened it at the left shoulder strap. So the phone could be easily charged while walking. I mounted it upside down to connect it more easily to the cable but that doesn't matter since the app writes a orientation flag into the photos EXIF data which tells how the picture is to show.
Due to the cumbersomeness of disconnecting, dismounting and peeling the phone out of the cover to switch to panorama mode, take some pictures, switching to walking mode, start recording, putting it in the cover, mounting and connecting it to the charging cable again I mostly did not do so.
At viewpoints or when making short rests I usually just stood there, had a look at the landscape and turned myself slowly around my own axis to let the app make images of the panorama. Only rarely (at big rests on mountain peaks or when walking a city on mapping purposes with the phone in the hand) I bothered to take pictures in panorama mode.
I just hope that there will be software intelligent enough which can detect little to no movement (based on GPS data) and overlapping image contents to stitch panoramas automagically.
At the hotel
After four days both powerbanks and the phone would be discharged so I had to spend a night at a place with electric power supply. Once I was five days "in the wild" so the last day went without Mapillary pictures.
Since I left the magnet charging cable at home due to bad charging performance and for reducing weight I had to calculate when to charge the phone and when to copy data since both at the same time doesn't work when using an OTG cable. When I intended to leave the hotel after one night it was a good idea to have the phone's battery charged in the morning so I tried to reach the hotel with a still quite charged phone, start copying as soon as I was in my room and before going to bed started charging the phone. Since I had two 128GB µSD cards with me capacity was the smaller problem. It really would have been easier if I had taken the magnet charging cable with me.
Nice side effect: I was also able to copy photos from my camera to the hard disk.
What I experienced so far on
I was lent the phone with two 10Ah batteries. With them it was possible to cover four days of hiking. But all the time the phone's statistics say 24% of the energy are consumed by the display. In my case without any use because the phone is mostly operated blindly – I could have done without display.
I installed the app BlackouT which dims the display but does not reduce the energy it needs. The app "screen standby" I found too, but to get it working one has to have the phone rooted and Busybox installed. Though the latter I managed I wasn't able to get root and the app working (during the trip in a hotel room).
Several times I had to reboot the phone since the app told me it could not access the camera. Not so often I had to reboot it due to the lack of recognized GPS satellites. Switching off the phone during the night reduces occasional reboots during the day, but does not eliminate them.
Although the camera is said to be a good one, it may only be a good one for smartphones. If you don't walk in the bright blazing direct sun there is a good chance the image is blurred due to slow shutter while moving.
Sometimes the phone got so hot it showed irreproducible behaviour. The only possibility was to reboot it.
The cover of the micro USB connector I attached and removed quite often. Soon the fitting didn't fit anymore and a little later went to pieces. Anyway I didn't dare to check if the phone is really waterproof. I preferred to have pictures during all the holiday to a drowned phone. The "worst" weather I used it was very light rain where I attached it to my rain coat in which I had glued a strip of loop fastener, too.
Software (Mapillary app)
Since I am no smartphone user at all I am not sure if this issue depends on Mapillary or a dedicated photo viewing app. Displaying the pictures taken is fine as long as there aren't too much of them and you want to see the most recent taken pictures (remember I took per average 4,5k pictures a day). You have to scroll down all the way by hand, you cannot grab the scroll bar and pull it down. And after you had a view at an image and went back to the list you are at its very top again. Even switching from displaying horizontal to vertical lets the list go back to the first image.
As mentioned above, sometimes the app could not access the camera and crashed.
When I experienced this live it was not too bad, but when it happens during recording I didn'tt realize this and walked on taking no more pictures. Even when I set the app to "make shutter noise when taking picture" it didn't not help much because after a while one becomes accustomed to the sound. Usually it took me a while to realize that the sound (and the recording) had stopped - especially in cases were the app takes pictures only now and then.
The same goes for "warn at $(certain_amount_of_memory_left)%". I am not sure if the phone did warn before, but once I discovered it showed up a message "picture could not be saved" after each picture taken. The SD card was full… Give the app a warning sound!
Due to the way I used the phone (described above) it was not easy to know the state it and the app were in. Often it happened that I set the app to recording, put it inside the cover and attached it to the shoulder strap – and there was no shutter sound. So to have a look what the issue is one needs to take the cover off again and peel the phone out. By the way most of the time the phone was connected to a spare battery to charge while walking which made "have a look at the display" still more complicated. It also happened that by pushing the plastic cover the touchscreen received input - and when this happened at the wrong place recording could stop. As "invincible mode" I suggest a kind of lock mode in which one has to enter a kind of unlock "code" – touching the buttons in a certain order – to be able to access the app.
Some speech commands to start/stop recording and switch the modes (walking/panorama) would be helpful.
Multi level panorama
Being on a mountain top one has a great view. So great even that making a panorama with only one row of images is not sufficient. With my "good" camera I usually take three rows for a big panorama:
- Sky with a little horizon
- Sky and horizon in equal parts
- Horizon and below
Write level to Exif
Since it is very likely the phone is out of level while walking it could be useful to store the degree the camera is out of level to be able to correct the image easily.
Good sequences (not shaky, not blurred and well matching images) Mapillary could present as time lapse movies.
To review this amount of pictures I struggled a little to find the best way. Just putting all the images in one folder and looking at them one by one is a slow method to sort them out. A lot of picture viewers are really slow on such a task, especially if they create a file list. The viewer ''feh'' is fast at displaying images from a folder containing zillions of them. But it still would take a lot of time to watch picture by picture. I finally chose to create a folders per each day and hour which is easy because of the naming of the images: 2014_08_14_18_25_30_374.jpg (year, month, day of month, hour, minute, second, splitsecond) Inside a folder containing images this line creates folders for each day and hour and moves the regarding images there: for i in $(ls -1 | cut -d "_" -f 1-4| uniq); do mkdir "$i"; mv "$i"*g "$i"; done With the picture viewer geeqie and fast preview settings it doesn't take too long to sort the bad images out. I mostly scrolled fast the preview thumbnails to find them. For me "bad images" are unintended selfies, shaky, over- and underexposed ones or where the biggest part of the images is obscured by stuff in front of the lens (trekking poles, arm, hand etc.).
Duplicates, triplets and so on I mostly didn't remove since some intelligent automagism could create a panorama from several files. After reviewing some thousand images I started to name these and "real " panorama pictures by adding "pano" to their name. For the little parts of the journey I used transportation I also named the images accordingly.
When the way goes steep uphill the pictures show a close up of the path without much landscape, often with the trekking poles. When descending the opposite happens: A lot of images seem to show the same piece of the landscape but not the path on which one walks downhill slowly.
Due to the walking movements it happens a lot that the phone goes alternating out of level to the right and to the left or shows alternating more of the left side of the path and then more of the right.
Really bad roads Mapillary cannot depict when the phone is mounted to a cars front screen. Either the car is too slow or it shakes too much. And when you hold the phone with your hands you sway it around a lot… In some days you can see how this looks on Mapillary – with the sequence from Kroi Bardhë to Kumbull.
As I wrote at the hardware section already: It is very hard to get unshaky pictures when walking around without bright sunlight. Using Mapillary in the early morning or late in the evening? No way you get good pictures with your smartphone.
When it comes to mapping it is of course not bad to have as much data available as possible. But loading all the images of just one day with JOSM requires a potent computer – and looking at each image for mapping gets soon tiring. You should still collect POI with your GPS/a matching app or make photographs of interesting POI with another camera to know, where the interesting parts to map are.
When you have uploaded all the images to Mapillary without local backup and want to map using them it gets difficult. You have the choice of either look at the images on the Mapillary site, draw your conclusions and use the editor of your choice. But for me being dedicated to JOSM this is an awful way to map with photos. Also the script ubahnverleih wrote to download images from Mapillary and get them into JOSM gives results which don't satisfy me. It creates a gpx file with the images embedded. Contrary to loading images directly into JOSM where you are able to scroll back and forward through them you have to click on each single icon to see the image thumbnail - and click once more to see it in high resolution. Afterwards you have to close two windows, too.
My recommendation: keep a local backup of the images until you are done with mapping.
- Mapillary is a nice way to collect images during (holiday) activities without bothering too much about technology.
- Due to hardware limitations of smartphones you need a lot of light to get good images.
- While walking it is not easy to make good, leveled and not blurred images.
- For mapping purposes (with JOSM): keep a local backup and still collect POI with another app/device to easily find the highlights of the journey.
Despite all worries, the 1kg extra load and some occasions I really cursed the stupid hardware¹ I want to thank the company Mapillary to enable me to collect that amount of data in remote regions of Albania. In some way every photo is historic but I think since Albania is a fast changing country and little known to most Europeans these images may get some attention.
¹ "Great! I walked that breakneck path, didn't fall down – and the camera didn't work and I have to spend some minutes for rebooting the phone and restarting the app!!1 %$§£Ω¤"
Since publishing this post I added some paragraphs, the image and fixed some minor errors
Soon I will hike central Albania starting in the Mirdita and after a double S course hopefully ending on the Tomorr.
Between my messages on twitter and on my Blog you can have a look at older journeys of mine from 2011 and [last year] (the latter two both in German, but there are also pictures).
Like last year I plan to have a walk in Albania during my holidays.¹ The planned route is this.
Though the mobile phones I use are Siemens ME45 I already had had contact with Peter Neubauer from Mapillary now and then and also heard him on Radio OSM (German OSM podcast #31). So I asked him about recommended hardware to run the Mapillary app for some days far away from civilisation and power sources and to store away the lots of images created.
In walking mode the Mapillary app is set to make a picture every two seconds as default AFAIK. After having had a first walk with Mapillary this seems to be a reasonable choice. Since my average day trip lasts up to eight hours and I assumedly will hike on 18 days I calculated the following:
pictures/minute x 60 minutes x 8 hours x 18 days x picture size 5 MB = assumed amount of created data
30 x 60 x 8 x 18 x 5 = 1.296.000 MB
After some mail exchange he sent me in the name of Mapillary the stuff we assumed would be best. Aside from the mounts mentioned in the other blog post I purchased an Y-OTG cable which allows USB drives to be powered from an external source while connected to the smartphone as host. Although there are dedicated backup devices – a HDD with battery and card reader attached² – we skipped purchasing such a device because it would have cost additional 250 EUR.
A list of the hardware:
- 2x 128 GB microSD card
- 1x magnet charging cable
- 2x deltaco Powerbank 10 Ah
- 2x short cables USB-A–µUSB- ~20 cm
- 1x long cable USB-A–µUSB- ~100 cm
- 1x µSD card reader für USB
- 1x 8 GB-µSD-card (assumedly forgotten in the reader)
- 1x OTG cable µUSB–USB-A-Buchse
- 1x Sony Xperia Z1 Compact (w/o SIM-card)
- 1x external 2,5" USB 3.0 drive 2TB
And two things I won't take with me
- 1x Speedport miniature 4xUSB-Hub
- 1x power adapter for the above
Last weekend I had everything ready to make a test under real conditions. The app was set to use continous autofocus and stable shot.
The following I could observe:
Running Mapillary about one hour discharged the battery by 30% and the phone got quite warm.
(I already had disabled/uninstalled a lot of needless stuff and installed BlackouT to dim the screen as far as possible to save energy)
Although I had walked for two hours Mapillary "only" made 1118 photographs needing 5220 MB of space. 30 images/minute in two hours would theoretically have resulted in 3600 images.
Speculations on the number of images:
Although the camera is a good one for smart phones with a 1/2,3'' ccd it in total numbers the lens is not fast. This results in low shutter speeds in shady environments and relative high noise.
When I walk through a dense wood, for one I am moving and this in a dimly lit environment. Although the camera is mounted near the shoulder where it is not moved too much the app still has to wait for moments where the movement is small enough to make pictures not blurred by movement. example sequence at mapillary
I'd also assume that the camera has problems focusing in low light.
I think these two points are the main reason that the number of recorded images is only one third of the images the app should have recorded theoretically.
Maybe one should also consider to mount the camera at the shoulder strap a little more to the sternum and away from the arm since it seems I lifted it a little with the arm sometimes.
Now for the quality of the images: As explained above the phones camera doesn't perform too well in shady environments.
I had not expected the number of defocused images I got (example). I assume this was mostly caused by me using trekking poles which I assume irritated the camera (you see them in some of the images). Since the continous autofocus also consumes some energy I disabled it which sets the camera to fixed infinity focus. So far I only could do a small walk with this setting and without poles but at least the pictures aren't worse.
Copying the remaining 4,4 GB of good images to the external drive took about five minutes. For testing purposes I had copied 32 GB of files sized ~50-100 MB from µSD (in the smartphone) to hdd which took 20 minutes.
It seems I cannot test how often I can charge the phone with one of the 10 Ah battery packs – I will see during holidays. The long cable mentioned in the list is for charging the phone while walking. This I also have not tested but I don't think there will be problems.
For now I thank Peter Neubauer and Mapillary that they allow me to add another 1,2 kg electronics to my luggage, to shoot (and later host) tons of images during my hiking trip – and most notably the confidence that they borrow me all the stuff.
¹ German blog post linking to some reports
¹ English description of hike at wikiloc
² Two not insanely expensive devices with 1TB are this and this
There is also the possibility to combine a barebone device with a HDD of the own choice, maybe with the additional battery for better being safe than sorry.
Since I got borrowed a Smartphone from Mapillary (more about that soon) but no mounts for car nor anything, I had to make up some.
As I needed one for the car I had nothing usable with me than an old T-Shirt which was dedicated for cleaning purposes.
I just ripped a strip from it – et violá:
lowest cost smartphone mount ever
A sequence recorded this way
A mount for walking was not as easy to create. I purchased what seemed to be a durable smartphone cover for about 8 EUR and a 30 cm long strip of 5 cm wide hook-and-loop fastener for ~1,50 EUR.
From hooks part of strip I cut two parts each as long as the smartphone cover was wide. Those I glued to the back of the smartphone.
The other half of the hooks strip I glued back to back to the loops strip.
So I had a wristband and was able to use the the smartphone as smartwatch with the biggest screen ever:
multi purpose scratchy wristband
Biggest and most inexpensive smartwatch ever
phone backside with hooks
(You should spare some loop strip to cover the hooks not covered by the mount. Else it could happen that the hooks stick now and then to the shirt you wear.)
But since I also want to use the smartphone with Mapillary while walking, I had to work a little more and punched some ugly holes into the side of the cover.
Now the phone could be put into the cover with the back to the front without the buttons being pushed all the time.
To use it while walking I put the hook-and-loop Band around the left shoulder strap of the backpack, let the Mapillary app record in walking mode, put it back-to-front into the cover and attach the latter to the hook-and-loop band (aka mount) at the shoulder strap.
Addendum: Maybe one should also consider to mount the camera at the shoulder strap a little more to the sternum and away from the arm since it seems I lifted it a little with the arm sometimes. I looking a bit knackered after walking some km with the stuff
This edit saved the world!!1:
(according to JOSM the ways length is 31.651m)
Today I exceeded the number of 1000 sent messages:
The number of received messages is 618.
Maybe others have sent more messages but in the beginning
- I was nearly the only active mapper in my region;
- there were little QA Tools (or I did not know them) and
- I had a lot work in my region so I had no as much time as now to bother other users. :)
Zu meiner Wanderung durch Albanien, die auch Grundlage für den Wanderreise-Vortrag bei den Linuxtagen war, gibt es nun detaillierte Berichte, Karten, Höhenmeterangaben und Fotos en masse.
Wer sich etwas Zeit mit der Lektüre oder dem Betrachten der Bilder vertreiben möchte: hier entlang.
Einige Bilder sind bei Wikimedia Commons besser aufgehoben.
Hochtal zwischen Dhëmbel- und Nemërçka by malenki; CC-by-SA 3.0
This nice willow tree I found last summer during my holidays. A nice view but not so nice for people with wheelchairs or prams.
I cannot help but share two images of a place I stumbled over today while mapping a little. A decaying house with a half collapsed outhouse at its side - but some flowers were well attended:
JOSM seems to get translated at transifex and launchpad, you can file bugs against JOSM at josm.openstreetmap.de and github, you can file bug against a lot of OSM things at trac.osm.org and github, too.
It doesn't matter when all resources are handled equally, but it is not so nice when you look at the wrong place…
Just read it at the tagging ML and cannot help but have to share it with you: Tag:natural=cloud
Hopefully some interested people will comment and vote on it – and the uninterested will use it for mapping.
OSM-Stand auf den CLT 2014 direkt nach dem Aufbau
Vergangenes Wochenende fanden die Chemnitzer Linuxtage 2014 statt. OpenStreetMap hatte wieder einen Präsentationsstand, an dem vielen Besuchern Fragen beantwortet werden konnten.
Wie üblich waren die Fragen der Besucher thematisch breit gefächert:
- Es gab auch dieses Jahr wieder einige Leute, die wissen wollten, was OSM eigentlich ist
- Einige Interessenten wünschten eine OSM-Karte für ihr Garmin-Gerät (und bekamen sie),
- Zwei Besucher waren (vor ~2 Monaten) beim Einbinden der OSM-Karte per SSL gescheitert. Der Rat war, es nochmals zu versuchen, da OSM Tiles erst seit kurzem auch per SSL ausliefert.
- Es wurde nach Möglichkeiten gefragt, OSM-Daten zu einer druckfertigen Grafik umzuwandeln.
- Zu Smartphone-Apps konnten wir auch einige Wissenslücken füllen.
- Die letzten zwei OSM-Tassen der vor drei Jahren georderten sechs fanden neue Besitzer; ein dritter Interessent ging leider leer aus. Ein paar OSM-Aufkleber wurden auch erstanden.
Den OSM-Nutzern und Standbetreuern strohi, Fuss-im-Ohr, Kolossos, ubahnverleih und vsandre nochmals vielen Dank für die tatkräftige Hilfe bei Vorbereitung, Aufbau, Abbau und der eigentlichen Betreuung des Standes. Allein hätte ich schwer zu kämpfen gehabt.
Der Vortrag Wanderreise mit OpenStreetMap hatte etliche interessierte Zuhörer, wurde mit Interesse aufgenommen wie mir schien und hatte einige Nachfragen zur Folge. Daher nehme ich an, dass er nicht völlig misslungen ist. :)
Für die 2-3 Zuhörer, die mit dem Schlaf zu kämpfen hatten, werde ich bei zukünftigen Vortragen versuchen, bessere Modulation und vor allem ein paar Spannungsbögen einzubauen. (;
Die Slides und das Bildmaterial sind bereits auf der oben verlinkten Vortragsseite zu finden. Da ich für Audio- und Video-Aufnahmen eine schriftliche Zustimmung geben musste, bin ich guter Hoffnung, das diese dort in naher Zukunft auch auftauchen.
Im Mai 2011 habe ich den Affiliate-Account für OSM.de bei amazon.de erstellt und kümmere mich seitdem darum. Gestern wurde die Auszahlung für Dezember 2013 in Höhe von 214,18 EUR überweisen.
Bis jetzt hat das Partnerprogramm des deutschsprachigen Amazon insgesamt 4448,35 EUR abgeworfen – eine hübsche Summe.
Vielen Dank an alle, die dazu beigetragen haben!
Ich frage mich allerdings, ob sich irgendwann jemand für amazon.com finden wird. 2011 hatte ich auch dort einen Affiliate-Account angelegt, aber mangels Konto in den USA die Account-Daten an OSM-US übermittelt und seitdem immer wieder mal bei verschiedenen Leuten gefragt, wie es steht. Kein Ergebnis…
Seit 2012 liegen dort $2.12 herum. Vielleicht würde es je helfen, wenn man den Betrag erhöhen würde.
Den amazon.com-Link habe ich der Wiki Merchandise Seite hinzugefügt und auch entsprechende OpenSearches auf der deutschen OSM Spenden-Seite. Man braucht die Seite nur mit Firefox zu besuchen und die Amazon-Suche für den Amazon-Zweig zu installieren, bei dem man einkauft: Einfach die Liste im Firefox-Suchfeld ausklappen und ganz unten die neue Suche auswählen.
Wenn man jetzt bei Amazon einkauft, nachdem man über den Link im Wiki oder über die installierte Suche dorthin gelangt ist, zahlt Amazon einen Anteil des Umsatzes an den zugehörigen OSM-Account aus – und damit an OSM.
In May 2011 I created the affiliate account for OSM.de at Amazon and maintain it since. Yesterday the money for December – 214,18 EUR – was transferred.
Until now the affiliate program of the German Amazon has payed with 4448,35 EUR – a nice sum.
Thanks to everybody who had their share on it!
But I wonder if there ever will be someone managing affiliates for amazon.com. In 2011 I had also set up an account for that Amazon branch. Due to the lack of an bank account in the US to connect with the account I communicated the affiliate account details to OSM-US. Since I have asked now and then how (if even) it is going – no definite answer so far.…
There are $2.32 waiting to become more since 2012 so maybe it would help if the money increases. :)
I've put the amazon.com-link to the Wiki Merchandise page and created OpenSearches at the german OSM donation page. Just visit the site with Firefox and install the Amazon search engine for the Amazon branch you shop at. Just open the drop down list at the search field and select the desired search engine at the bottom.
Now if you shop at Amazon after using the affiliate link from the wiki or a search engine connected to an OSM affiliate account, Amazon will pay a certain share of the revenue to the account – and thus to OSM.
Out of curiosity I had a look for maxspeed= with values that contain at least one semicolon on taginfo.
It is most likely that this kind of maxspeed values are created by merging at least two highway segments with different maxspeed values.
If you want to have a look yourself click here and type a ";" in the (lower) search box for values.
Accumulating the numbers there are 1058 key-value-pairs containing a semicolon.
Interpolating this one can consider that supposedly at least 2116 highway segments got merged without the mapper taking good care about what he did. Looking at the topic it seems obvious that often more then two segments got united.
I do not know of any Quality Assurance tool which is checking for this kind of errors. If you do, please mention it at the comments.
More important than to fix this data is not to create new errors of this kind.
- Luckily the default behaviour for merging ways in JOSM has been altered from combining the values as "value1;value2" by default. Now the user is forced to select one of the conflicting values.
- In Potlatch2 combined values are shown in red with a warning sign.
- iD merges ways with conflicting tags without complaining. Of course there are no plans for an intrusive warning because "they run counter to iD's goal of encouraging new users to contribute to the map because they make them feel insecure, even when their edits are perfectly legitimate"(link). Another issue against iD regarding conflicting tags is a year old.
Overpass-Turbo-Abfragen mit "in Hamburg" funktionieren nicht.
Der Grund ist vermutlich, dass es zwei Relationen mit name=Hamburg und type=boundary gibt. Die eine ist die "echte Hamburger" Grenze und schließt ein paar Inselchen in der Nordsee mit ein. Die andere Relation ist bis auf die Grenze um diese Inselchen und ein paar Tags mit der Grenzrelation identisch.
An letzterer bestimmend soll wohl dies sein:
note=Hamburg city (enclosed urban settlement)
Wer räumts auf?