May 24, 2016

" User's Diaries"

OSM loves Mapillary

When looking through the pages of Open Street Map community at Google+, I stumbled upon an article about collaboration between Open Street Map and Mapillary. Mapillary – is a service for sharing of geotagged photos developed by Mapillary AB, located in Malmö, Sweden. The goal of the company is to represent the whole world (not only streets) with photos using Crowdsourcing. What got me interested is that geotagged photos may be used for OSM map data creation because they licensed under CC-BY-SA license, availability of the plugin for the popular JOSM editor and possibility to turn on Mapillary layer in web-based iD Editor. Mapillary service is an alternative to Google Street View and Yandex Panoramas except that it is users who provide photos for the service. Mapillary service has apps for the mobile phones based on Android, Windows Phone, iOS and BlackBerry OS. But shooting photo-sequences with your phone while you walk or ride bicycle is not very comfortable, besides that phone battery dies very quickly, mount for the phone could be unreliable etc. That’s why in this article I will describe how to create panoramas for the Mapillary service using action camera. When you use Mapillary app on your phone all exif-tags that are necessary for photo geolocation (coordinates and shooting direction) acquired automatically because phones mostly come with compass and GPS unit already built-in. Action cameras usually doesn’t have built-in GPS unit (not like Sony Action Cam HDR-AS30v) that’s why we would need GPS-track for manual geolocation of photos.

What we would need is:

  1. Action camera with car/bicycle mount that can shoot in time-lapse mode. I use cheap but powerful Xiaomi Yi Action Camera.
  2. Device that could record GPS-track. It could be GPS-logger or mobile phone with GPS, or combination of both. I use GPS-logger HOLUX RCV-3000 connected to the phone by Bluetooth and mobile phone with OSMTracker (Android) app installed to record GPS-track. If satellites are dispersed in the sky-evenly in each direction HOLUX RCV-3000 could output GPS data with 1.7 meters accuracy.
  3. A little mind-twisting (dance with a tambourine – in original article, from Ukrainian) around Python, wideband internet access for manual photos upload to Mapillary.

Now in detail:

Start your GPS device and leave it in the place with clear visibility of the sky until GPS position is fixed (for better accuracy let it be for at least 5 min), after GPS position is fixed start GPS-track recording, make a picture with your camera of your phones current time with precision to the seconds (may be needed later for synchronization and setting offset), then start your camera in time-lapse mode and start to move through streets/places for which you wish to create Mapillary photo sequences, when you done export data from OSMTracker into .gpx-file. For the bicycle ride I chose shooting interval of 2 seconds, for the car which could move much faster would be vise to select shorter interval, the camera mentioned above could do time-lapse mode with interval up to 0.5 seconds, as long as fast class micro SD card installed. In my case I still make picture of the phones clock with the camera and make sure that camera clock is synchronized with phones clock, in the OSMTracker Preferences menu I check box to ignore GPS-time and use phone-time (my local time) for the time stamps. screenshot_OSMTracker In that way photos from camera and time stamps in .gpx-file will be in the same time zone and already synchronized, if you didn’t do that you still could correlate photo position with GPS-track later in JOSM as long as you took photo of your phones clock. As a result we got a sequence of the photos and .gpx-file of recorded track. For convenience create a folder named with current date and copy photos and .gpx-file in that folder. It is recommended to create a backup folder here as well and copy all photos in it before making any changes in case something will go wrong.

Geotagging photos

There many ways to geotag a photo ranging from use of Windows-programs and to Python scripts or libraries/ modules Ruby Gems on Linux-like operating systems. I will describe two the most easiest ways for the common user:

Geotagging with old and powerful JOSM:

I use JOSM for tagging photos with GPS position, it’s simple and fast to use.

  1. In order to write exif-data to the photos after we synchronized them with GPS-track in JOSM, we need to install Photo Geotagging plugin. Go to the JOSM Preferences (F12)>>Plugins tab>>Search for Photo Geotagging and check the box to install, after installation restart JOSM. photo_geotagging_en

  2. After JOSM is started>>Open .gpx-file and add photos to the loaded GPS-trak, set correlation to 0, because our track recorded using local time zone (phones time), if GPS-track was recorded without prior correction (GPS time is always in UTC 0:00 time zone) then you need to correlate the difference in relation to Greenwich. The best way to do this is to determine the difference from the first picture we took of mobile phones time on the screen, just select this option from dialog and enter the time you see on the picture, in result all sequence will be lined up properly. open_gpx_and_photos_en

  3. Then just right-click the “Geotagged Images” layer and select “Write coordinates to image header”, then yes. Additionally you could check the box on the “keep backup files” option if it wasn’t done earlier. Saving of changes is very fast. save_photos_en

  4. After those steps is done each photo should have coordinates and altitude above sea level (if altitude above sea level was recorded to .gpx-file). To check this you could use simple program called ExifTool by simply dragging photo on the program icon. file_check

Alternative way using freeware-program GeoSetter

  1. Run GeoSetter and in the directory choose dialog select folder with photos which you would like to geotag. open_photos_geosetter

  2. Select all photos in the folder (Ctrl+A) and push on the “Synchronize geo data of selected images with GPS data files” button (Ctrl+G) which will call the dialog window to choose GPS-track and synchronization parameters setup. select_img_and_syncronize

  3. Choose .gpx-file (if track in the same folder as photos, option to use track from that folder will be automatically checked), if needed choose parameters for correlation and press OK. If photo time stamps (Original Taken Date tag) and .gpx-file track-points time in the same time zone program will tell us that GPS positions was found for some amount of the files. If photos doesn’t match the time of .gpx-file track-points you need to set time zone difference. After photos is synchronized don’t forget to save the changes by pressing either floppy disk icon or Ctrl+S key combination. It takes a lot more time to save changes compared to the JOSM. img_syncronized

  4. After those steps is done each photo should have coordinates and altitude above sea level (if altitude above sea level was recorded to .gpx-file). To check this you could use simple program called ExifTool by simply dragging photo on the program icon.

Preliminary photo adjustment and compression

This step could be skipped if you have broadband internet connection with high speed of upload. This step should be done before image direction is calculated because in my case Adobe Lightroom deleted “GPS Img Direction” tag from file header, ignoring the fact that I chose to leave all metadata as is. After import into Adobe Lightroom automatic tone and white balance was done to all photos, then photos exported at the same resolution but with compression to 700 kB and sharpening option for the screen. You could use trial version of Adobe Lightroom, which is free, and continue to work with limited functionality after the trial license expiration date. Tab “Library” still remain active with and you could use “Quick develop” standard presets to do the adjustments. Check out this article for more information. Mapillary team in their instructions recommends to use freeware editor IrfanView, which could do the batch processing of the files.

Setting up Python environment for use of Mapillary Tools scripts.

Prerequisite for this step is installed and properly set up Python programing environment, in our case we would need Python version 2, latest release could be downloaded here. How to properly set up Python could be checked here. Then we would need Mapillary Tools scripts, they could be downloaded from project GitHub page. Unpack archive for example in your user Documents folder. Not entirely full and precise article on how to run Mapillary Tools scripts in Python here. First we need to install a few libraries/packages by means of pip (Python Package Manager) in order for Mapillary Tools scripts to work:

  • exifread – installed by means of pip.
  • gpxpy – installed by means of pip.
  • PIL – installed by means of pip.
  • pyexiv2 – installed using Windows-installer, depending on the version of your Windows OS x32 or x64.

Now in detail:

Run Windows command line, by means of Run menu (Win+R), enter “cmd” into the search field. run_cmd We need to check if Python is working, enter “python” in command line, if everything was set up i.a.w. instruction in the link above, then Python command interpreter should start. You can tell that Python interpreter started by the appearance of “>>>” in command line, now you could do simple commands like “print (“All hail OSM”)” and simple math operations. check_if_python_set_up_properly simple_operations_en After we checked that Python set up properly, close the command line and start it again. Then we need to install necessary packages necessary to run Mapillary Tools scripts, namely: exifread, gpxpy, Pillow, pyexiv2 package installed manually by running the installers from the links above. Python (version at the time article was written 2.7.11) by default installed to the following file path: C:\Python27\python.exe. Along with the Python itself, Python Package Manager “pip” installed as well, in my case path to the pip is: C:\Python27\Scripts\pip.exe. In command line change directory to the C:\Python27\Scripts\ in order to run “pip.exe”, for that type in the command line “cd C:\Python27\Scripts\” (path could be simply copied and pasted into command line by right-clicking the mouse over the cmd window, without need to type it manually) change_directory_to_pip Then enter one by one and observe the progress of the packages being downloaded and installed. pip install exifread pip install gpxpy pip install Pillow Because those packages already installed on my system, I only receive message to update the package and the path to witch it was installed: install_packages If everything went well and without errors, then Python environment is ready Mapillary Tools scripts execution.

Calculating the image direction with use of Python scripts.

First I need to mention that Mapillary Tools has a lot of scripts for image processing and further upload to the Mapillary service, including the script to geotag the photos, but not all of them are working or work incorrectly, and author of the scripts mentioned this in the comments to the scripts. For example, I didn’t manage to geotag my photos (currently in correspondence with the scripts developer to resolve the issue), that’s why I described two easier ways to do that in this article. But fortunately, script for calculation of direction photo was shot, in my case, is working and very quickly calculates and writes image direction tag in degrees based on the coordinates of the next photo that was taken in time-lapse sequence. Thus, let’s start calculation of the direction photos were shot. At this step we already have a folder with photos that already has GPS coordinates and time stamps and only thing we need is to enter the path to the script, then to the folder with photos and camera angle offset in regards to the direction we moved. If camera was pointed in same direction to which we moved, then angle offset will be “0”. Scripts are in the archive Mapillary Tools that we downloaded and extracted earlier in the Documents folder. In my case path to the script “”, which we need is: “C:\Users\vfedo\Documents\Mapillary\mapillary_tools-master\python\” Path to the folder with photos: “D:\Mapillary\19.05.2016\backup” Then run the command line and enter: python “C:\Users\vfedo\Documents\Mapillary\mapillary_tools-master\python\” “D:\Mapillary\19.05.2016\backup” 0 (you could use quotation marks or not, it doesn’t matter, but it helps me to outline separate parts of the command) interpolate_direction_script After the script is done its magic we have geotagged photos which has direction of shooting and ready to be uploaded to the Mapillary service. You could check the direction of photos visually in the GeoSetter program by selecting directory with photos and switching from photo to photo by arrow key, this will help to detect the photos which was possibly processed incorrectly by “” script, for example when you wait for the green light GPS-track points will be “dancing” around your real position, due to the GPS unit working principle and possibilities, thus the direction of such images will be calculated improperly, consider deleting such photos from sequence before you upload to Mapillary. Direction could be set after you upload to Mapillary as well, but it will take long to process, (currently service accepts up to 100 changes at time from the editor) and even if you could see that the angle was set for the photo in editor it still points to the north and when you check them in JOSM it’s the same. That’s why to get quality sequence better upload completely ready photos (that include tags: "GPSLongitude", "GPSLatitude", "DateTimeOriginal" та “GPSImgDirection” in the exif header). If photos still were uploaded to the server without “GPSImgDirection” tag, it could be corrected in the editor for the whole sequence: enter the editor and check the box to set the direction angle so each photo will be facing next photo in the sequence and if needed specify the offset angle. Offset angle is counted clock-wise in the North-East system of coordinates in range from 0 to 359 degrees. For example, if camera was pointed from left window of the moving car, then angle offset will be 270 degrees (or -90 degrees, which is same direction). While testing, three of mine first sessions were (1, 2, 3) were uploaded without proper tag “GPSImgDirection” and though I edited them on Mapillary they still facing North on the service and in JOSM, maybe Mapillary team will fix that over time. There are upload scripts as well, but in this article I will describe manual upload in the web-browser, so you could see if photos were geotagged and processed correctly.

Uploading to Mapillary

In order to be able to upload photos to Mapillary service you need to create user account. After your successful registration go to the right upper corner and by clicking your user name you could set up your profile, go to your profile or start Manual Uploads. mapillary_user_profile Go the Manual Uploads and press Choose Files, select photos for upload and Mapillary will check them: upload_dialog If all necessary tags are present, then you will see photo sequence connected by line and each photo has the direction arrow: check_before_upload Then press Upload and wait for upload to be finished: press_upload If during upload process the progress shown in percent doesn’t change or your internet connection disconnected, you could continue to upload by pressing “Upload hung up? Click here.” link. upload_hung_up Page will update and show the photos that already uploaded, and the option to upload more photos to the sequence and Publish Sequence or cancel. Select upload more photos to the sequence and choose all photos again, Mapillary will check them, discard the duplicates and offer to upload rest of the photos, showing them on the mini-map with orange points. upload_more_photos_to_this_sequence After upload finished, better to double-check the amount of photos in the folder. Everything seems right 646 photos uploaded. Now you could click Publish Sequence and receive a high five for the good work. Now let’s find out how to use photo data from Mapillary for mapping in OSM. publish_sequence

Using Mapillary service for mapping in OSM

Because we can use photo data from Mapillary to map the objects in OSM, let’s check how to do it with two most popular OSM editors, namely JOSM and iD Editor.

Using Mapillary with JOSM:

In order to use Mapillary service with JOSM and be able to set Mapillary imagery as a layer we need to install pugin of the same name. For that go to the JOSM Preferences (F12)>> Plugins tab>> Enter Mapillary into the search line. Restart JOSM after plugin installed. install_mapillary_plugin_en After JOSM is started load the map data for the area that has Mapillary coverage. Mapillary coverage could be checked at this web-page, enter your location or zoom in to it, by red lines photo sequences are shown. mapillary_map_coverage I will download an area of my own town, for which I uploaded photo sequence earlier. After OSM map data layer is loaded, Mapillary photo layer could be loaded by going the menu Imagery>> Mapillary (or by keyboard shortcut Shift+comma). mapillary_in_josm_en

Using Mapillary with iD Editor:

It is easy to make iD Editor show Mapillary photo layer, just enter the Edit mode for the chosen area, then click on Map Data button (shortcut F) and choose Mapillary photos. After that Mapillary photo layer will appear, showing the photo direction and photo markers which you could click to fix or hover you mouse pointer over them. (screenshot left as in my original post, i.e. iD Editor layout with Ukrainian language) mapillary_in_id_editor


Mapillary and OSM collaboration plays a big role in both projects development. This How To was created with intention to inspire OSM community to increase Mapillary coverage, because most likely small towns and other places don’t have it, and use of commercially available analogs for mapping in OSM is prohibited.

My Mapillary profile and first proper sequence.

Beautiful gif-animation was created with use of open-source program ScreenToGif.

This is translation of my original article, I am not native English speaker, if you find any mistakes please leave a comment, also share this with your local OSM community and any social network, feel free to use material in the article to translate it into your mother language with reference to this article.

Happy and productive mapping to everyone.

by Blackbird27 at May 24, 2016 11:17 AM

May 23, 2016

" User's Diaries"

Taller de Mapeo Libre en la UNAM México

El pasado sábado 14 de mayo llevamos a cabo la segunda jornada de #MapeoLibre, en la continuidad de la jornada en la UAEMEX en Toluca. Este formato nos parece ser un buen cruce entre las enseñanzas técnicas con el uso de aplicaciones web y de campo, un panorama de distintas maneras de colaborar con Openstreetmap, y es también la ocasión de informar y tener retroalimentación sobre los tipos de proyectos y colaboraciones que pueden ser desarrollados explotando el material y los datos de Openstreetmap.

Llevamos a cabo estas jornadas en serie: la primera fue en la UAEMEX, seguimos con la UNAM de la Ciudad de México (facultad de Ingenieria), y estamos planeando las próximas en 3 otras universidades públicas para el próximo semestre. El formato combina conferencia teórica práctica y actividades con distintas herramientas sobre un día completo. En esta ocasión la jornada incluía:

  • Una introducción general a los datos abiertos, al uso de los datos para muchos propósitos entre cuales las políticas públicas y la investigación, presentamos algunos casos de proyectos con fines variados basados en Openstreetmap: el mapeo de Lerma (Estado de México), y el proyecto #Repubikla.
  • Una capacitación para Id Editor donde como en la experiencia pasada en la UAEMEX de Toluca enfocamos en ejercicio sobre el campus universitario.
  • Una introducción a HOT y al task manager con un ejercicio en un proyecto de nivel mediano de emergencia, en Ecuador.
  • Capacitación y ejercicio de campo con Mapillary y OSMtracker en el campus. Para el levantamiento de fotos con Mapillary, incentivamos los participantes a abonar al ejercicio de #Mapeaton, una cuenta colectiva creada para documentar masivamente las condiciones de tránsito y accesibilidad peatonal y en sillas de ruedas (estado de las banquetas, de los accesos, rampas, etc.).

Participamos en esta dinámica: Alberto Chung, Eldesbastemap, Ealp, Juane90, Josuer, Mapanauta, Mapeadora, Tavooca, Yoltotolhua.

La asistencia fue numerosa, equivalente a las jornadas en la UAEMEX, con cerca de 80 personas. Asistieron estudiantes de la facultad (una mitad aproximadamente), pero también profesores, personas de organizaciones sociales invitadas en el marco de otros talleres que hemos dado estos meses (3er Congreso Peatonal), personas de instituciones públicas con quienes estamos desarrollando colaboraciones, de la Ciudad de México y de otras entidades (Hidalgo). A raíz de estas capacitaciones masivas, estamos construyendo una red de difusión siempre más amplia, buscando tener más impacto en el fortalecimiento de la comunidad mapera de México y en el conocimiento de OSM por las instituciones públicas y las universidades.

Desde la jornada en la UAEMEX, buscando tener una dinámica que afiance el aprendizaje entre los asistentes, y hacer de ellos maperos constantes. Desde el evento de la UAEMEX, lanzamos una iniciativa de competencia de ediciones sobre un mes contando a partir de la fecha del evento, con un reconocimiento para los 5 mejores mapeadores. Para eso pedimos el uso de un hashtag en el changeset (#MapeoLibreUNAM, en este caso, junto con #mapathon), para monitorear los cambios, con las siguientes herramientas: y

Posteamos sobre el progreso durante el mes de competencia para motivar el grupo, mientras se gestionan regalos con patrocinadores. Esta acción sirve una triple estrategia: dar seguimiento a los usuarios y crear comunidad; seguir capacitando más allá del marco del taller, con la posibilidad de detectar y comunicar sobre errores recurrentes, fortaleciendo sus habilidades; sembrar un gusto por el mapeo. Se busca dejar un resultado emblemático y visible: el campus donde se realiza el evento y sus alrededores.

Cada actividad dio lugar a un diálogo enriquecedor con los asistentes, con preguntas tanto teóricas como técnicas, interés para conocer herramientas mas avanzadas, ideas inspiradoras y proyectos, con los cuales eventualmente podemos colaborar formalmente. También establecimos una dinámica post evento de feedback entre los instructores, discutiendo comentarios hechos individualmente por los participantes, como impresiones nuestras para mejorar siempre la dinámica. Nos pareció por ejemplo necesario tener en próximas sesiones un tiempo dedicado a lluvia de ideas con los asistentes sobre posibles proyectos, colaboraciones, o cómo las herramientas de OSM pueden servir sus proyectos actuales.

En cada uno de los talleres dados desde hace 8 meses (han sido 12 entre los talleres de Openstreetmap, de Repubikla y Mapillary/Mapeaton) se ha generado un gran potencial de colaboración con proyectos vinculados a OpenStreetMap o a herramientas de la comunidad. Siempre hemos descubierto visiones novedosas sobre temas de mapeo, un ejemplo reciente (en el marco de un taller de Repubikla en Morelia con el colectivo Bicivilízate) es el mapeo como performance de la memoria, #PerformanceDelCaminar, sobre los desaparecidos en el estado de Michoacán donde Fabiola Rayas, con enfoque artístico, documenta y recrea el último recorrido conocido de los desaparecidos junto con la familia y la comunidad (será el objeto de un próximo post).

by mapeadora at May 23, 2016 07:14 PM

Creating a New Diary Entry "Parsed by Markdown"

I'm trying to understand how to interpret the "Parsed by Markdown" table that appears next to the text "Body" in the OSM "New Diary Entry" form.

I understand to add a heading I must prefix it with a pound sign followed by a space "# " :

This is a heading

To create an "Unordered list" you prefix the text with an asterisk followed by a space "* "

  • First item in an unordered list
  • Second item in and unordered list

Similarly an "Ordered list" is a number followed by a period and a space "1. "

  1. First item
  2. Second item

A link is to be entered by using the format "[Text](URL)". Here you retain the brackets and parenthesis and replace the word "Text" with the name of the URL and letters "URL" with the actual web address.

Here's an example where I replaced "Text" with "OSM Diary Form" and URL with ""

OSM Diary Form

The last example for displaying an image is giving me trouble. The problem is that you need to use a URL for an image and the places I store photos like Flicker and Google Photos don't allows you to copy the link to the image file.

The format is "[Alt text](URL)".

by Alan Bragg at May 23, 2016 03:09 PM

Review: OsmAnd: Navigating With OpenStreetMap

As promised before, here's my review of a navigation application based on OpenStreetMap data, OsmAnd:

OsmAnd: Navigating With OpenStreetMap

I have to say that when I started using OsmAnd+ for surveying location, I saw occasional rendering hickups. It was not as pleasant as the other mapping applications, but it was still doing it's job.

Things changed dramatically when I tried using it on the roads with 45 mph (76 km/h) speed limit with complex intersections where zoom in/zoom out or turns caused the whole thing to redraw so furiously it was hard to keep track of what was where.

I posted a number of videos to show what I mean and I regret to say that I ended up with a result completely different to what I've hoped.

Yes, it is Open Source, and it has a ton of features (and almost awesome OSM Live!), but I just cannot use it for car navigation, sorry.

by ryebread at May 23, 2016 03:00 AM

May 21, 2016

" User's Diaries"

Entrevista a la comunidad OSM en Perú

Recientemente nos hicieron una entrevista en la televisión pública del país, nos reunimos en el campus de la Universidad Nacional Mayor de San Marcos en Lima para explicarles a los periodistas nuestro trabajo con OpenStreetMap y nuestra participación en algunos proyectos como Mapazonia. En la entrevista participamos miembros de OpenStreetMap Perú y Mapbox Ayacucho. El vídeo OpenStreetMap y Mapazonía en Perú 7'' ha sido extraído de la versión original del programa Umbrales que se llamó "La revolución de los mapas" 1'1''. Le hemos agregado subtítulos en ingés y en francés para compartirlo con la comunidad OSM en el mundo.

Que lo disfruten!

by johnarupire at May 21, 2016 11:58 PM

May 20, 2016

" User's Diaries"

OSM любить Mapillary

Переглядаючи сторінки спільноти Open Street Map в Google+ наткнувся на статтю про співпрацю Open Street Map та Mapillary. Mapillary – це сервіс обміну фото з геотегами заснований Швецькою компанією Mapillary AB з Мальме. Мета компанії – представити весь світ (а не тільки вулиці) фотографіями за допомогою краудсорсингу. Мене зацікавило те, що геотеговані фотографії можна використовувати для створення даних в OSM, так як вони розповсюджуються по ліцензії CC-BY-SA та наявність втулка для популярного редактора JOSM і можливість підключення шару Mapillary у веб-редакторі iD. Сервіс Mapillary аналог сервісів Google Street View та Yandex Панорами, за виключенням того що користувачі самі наповнюють даний сервіс фото. Сервіс має додатки для телефонів на базі ОС Android, Windows Phone, iOS, BlackBerry OS. Проте зйомка з допомогою телефону серії знімків під час ходьби чи їзди на велосипеді не досить зручна і батарея телефону швидко розряджається, кріплення для телефону може бути не надійне і т.д.. Тому в даній статті я опишу те, як створювати панорами для сервісу з допомогою екшн камери. При використанні додатка Mapillary на телефоні, exif-теги необхідні для геолокації знімка (координати та напрям зйомки), записуються автоматично, так як телефон має вбудований компас та GPS. Екшн камери зазвичай не мають вбудованого GPS приймача (як наприклад Sony Action Cam HDR-AS30v), тому нам знадобиться GPS трек для ручної геолокації знімків.

Що нам знадобиться:

  1. Екшен камера з кріпленням (присоскою) для автомобіля або велосипеда, з можливістю зйомки фото з інтервалами (time-lapse). Я використовував дешеву та сердиту Xiaomi Yi Action Camera.
  2. Пристрій з можливістю запису GPS треку. Це може бути або GPS логгер, або телефон з GPS, або зв’язка двох пристроїв. Я використовую GPS логгер HOLUX RCV-3000 з’єднаний з телефоном по блютузу та встановлений на телефон OSMTracker (Android) для запису GPX трека. При “правильному” розміщенні супутників HOLUX RCV-3000 здатен видавати GPS дані з точністю до 1,7 метра.
  3. Трохи танців з бубном навколо Пітона (Python), широкосмуговий доступ до мережі інтернет для ручного завантаження знімків на Mapillary.

Тепер детальніше:

Запускаєм GPS пристрій, залишаємо його на місці до фіксації супутників (для кращої точності), після фіксації GPS починаємо запис GPS треку, запускаємо камеру на зйомку в режимі time-lapse і рухаємось по вулицях/місцях, для яких хочемо створити панораму, після завершення експортуємо дані з OSMTracker в .gpx-файл. Для велосипеду я вибрав інтервал зйомки 2с, для автомобіля який рухається швидше, є сенс вибрати менший інтервал, вищезгадана камера підтримує інтервал до 0,5 секунди. В моєму випадку я переконуюся, що годинник моєї камери синхронізовано з телефоном, а в налаштуваннях OSMTracker вибрана опція ігнорувати час GPS та використовувати час телефону для часових міток. скріншот OSMTracker Таким чином знімки з камери та часові мітки в .gpx-файлі будуть в однаковому часовому поясі та уже синхронізовані, якщо цього не зробити, то кореляцію можна провести пізніше при синхронізації знімків з GPS треком. Як результат отримали послідовність знімків та .gpx-файл записаного треку. Для зручності створюємо теку з поточною датою куди копіюємо наші знімки та .gpx-файл. В даній теці бажано створити теку “backup” куди також скопіювати наші знімки, як резервну копію, якщо щось піде не так.

Прив’язка знімків до GPS координат

Існує багато способів прив’язати знімки до GPS координат, від використання Windows-програм до використання Python-скриптів чи бібліотек Ruby Gems на Linux-системах. Я опишу два найпростіших:

Прив’язка за допомогою старого доброго JOSM:

Я використовую даний спосіб, простий і швидкий.

  1. Для запису координат до exif-даних знімків після їх синхронізації з gpx-треком у JOSM нам спочатку потрібно встановити втулок Photo Geotagging. Для цього заходимо в Налаштування JOSM (F12)>> вкладка Втулки>> Вводимо в рядок пошуку “ geotag ” та обираємо втулок, після встановлення втулка бажано перезапустити JOSM. photo_geotagging

  2. Запускаємо JOSM>>Відкриваємо наш .gpx-файл та додаємо наші зображення до GPS-треку, задаємо зміщення 0, так як наш gpx-трек записаний за місцевим часом (часом телефону), якщо ж трек записаний без попередньої корекції (GPS-час в UTC 0:00), то необхідно підібрати зміщення місцевого часового поясу відносно Гринвіча. open_gpx_and_photos

  3. Далі просто правою клавішею викликаємо меню на шарі “Зображення з геотегами” та обираємо пункт “Записати координати в заголовок зображення”, тиснемо так. Додатково можна поставити галочку на пункті “зберегти резервні копії”, якщо знімки не було зарезервовано раніше. Збереження змін дуже швидке. save_photos

  4. Після даних операцій кожен знімок повинен містити координати та висоту над рівнем моря, якщо даний параметр наявний в .gpx-файлі. Перевірити можна з допомогою простого додатка ExifTool просто перетягнувши файл знімку на іконку програми. file_check

Альтернативний спосіб з допомогою freeware-програми GeoSetter

  1. Запускаємо GeoSetter та в рядку вибору каталогів вибираємо каталог зі знімками, які ми хочемо прив’язати до координат. open_photos_geosetter

  2. Виділяємо всі знімки в каталозі (Ctrl+A) та натискаємо на іконку “Синхронізувати геодані вибраних знімків з геоданими GSP-файлів” (Ctrl+G), після чого з’явиться діалогове вікно для вибору GPS-треку, та налаштування параметрів синхронізації. select_img_and_syncronize

  3. Обираємо .gpx-файл для синхронізації (якщо трек в тому ж каталозі, що і зображення, обирати не потрібно), якщо необхідно обираємо параметри зміщення та натискаємо Ok. Якщо часові мітки знімків та .gpx-файлу знаходяться в одному часовому поясі, то програма повідомить нам, що GPS-дані були знайдені для певної кількості знімків. Якщо не було знайдено знімків, які відповідають часовим міткам .gpx-файлу, то необхідно встановити зміщення часового поясу. Після синхронізації не забуваємо зберегти геотеги до знімків, натиснувши на іконку дискети або комбінацію (Ctrl+S). Збереження проходить значно довше ніж в JOSM. img_syncronized

  4. Після даних операцій кожен знімок повинен містити координати та висоту над рівнем моря, якщо даний параметр наявний в .gpx-файлі. Перевірити можна з допомогою простого додатка ExifTool просто перетягнувши файл знімку на іконку програми.

Попереднє стиснення зображень

Даний крок можна пропустити при наявності якісного широкосмугового доступу до інтернет з високою швидкістю відвантаження. Даний крок потрібно виконати до розрахунку напряму зображення, так як в моєму випадку Adobe Lightroom видалив тег GPS Img Direction з шапки файлу зображення, незважаючи на те, що при збережені був вибраний пункт збереження всіх метаданих. Після імпорту в Adobe Lightroom було виконано автоматичну корекцію одного зображення, після чого дані корекції скопійовані на інші зображення, далі зображення експортовано зі стисненням розміру до 700 кБ без зміни роздільної здатності та збільшення чіткості для екрану. Команда Mapillary в своїх інструкціях рекомендує використання freeware редактора IrfanView для масової обробки файлів.

Налаштування середовища Python для роботи зі скриптами Mapillary Tools

Передумовою даного кроку є установлене та правильно налаштоване середовище програмування Python, в нашому випадку нам потрібен Python версії 2, крайній реліз можна завантажити тут. Як правильно налаштувати Python можна прочитати тут англійською. Далі нам будуть потрібні скрипти Mapillary Tools, завантажити їх можна з GitHub тут. Архів бажано розпакувати на диску С в теку Документи користувача, так як диск С є робочим середовищем для Python. Не зовсім повна та коректна стаття про те як запускати скрипти на Python для Mapillary знаходиться тут. Далі для правильної роботи скриптів Mapillary Tools, попередньо доведеться встановити декілька бібліотек/пакунків через pip (Менеджер встановлення пакунків), а саме:

  • exifread – встановлюється через pip.
  • gpxpy – встановлюється через pip.
  • PIL – встановлюється через pip.
  • pyexiv2 – встановлюється через встановлювач Windows в залежності від версії системи x32 або x64.

Далі детальніше:

Запускаємо командний рядок, через команду Виконати (Win+R), в поле вводимо “cmd” run_cmd Перевіряємо чи працює середовище Python, вводимо в командному рядку “python”, якщо все налаштовано згідно інструкцій в посиланні вище, то повинен запуститися інтерпретатор Python. Про запуск інтерпретатора Python свідчить поява >>> в командному рядку, тепер можна виконувати прості команди такі як “print ("Слава OSM")” та прості математичні операції. check_if_python_set_up_properly simple_operations Коли впевнилися, що середовище Python налаштоване правильно закриваємо дане вікно та повторно запускаємо командний рядок. Далі встановлюємо пакунки необхідні для запуску скриптів Mapillary Tools, а саме: exifread, gpxpy, Pillow, бібліотеку pyexiv2 встановлюємо вручну за посиланнями наданими вище. Python (поточна версія 2.7.11) за замовчуванням встановлюється за таким шляхом C:\Python27\python.exe. Разом з Python інсталюється Менеджер встановлення пакунків “pip”, в моєму випадку його було встановлено в C:\Python27\Scripts\pip.exe. В командному рядку переходимо в теку C:\Python27\Scripts\, щоб задіяти можливості “pip.exe”, для цього набираємо в командному рядку “cd C:\Python27\Scripts\ (шлях можна просто скопіювати та вставити в командний рядок натисканням правої клавіші миші): change_directory_to_pip Далі вводимо послідовно та спостерігаємо за процесом встановлення пакунків: pip install exifread pip install gpxpy pip install Pillow Так як дані пакунки уже встановлені в моєму середовищі Python, то з’являється тільки пропозиція оновити дані пакунки: install_packages Якщо все пройшло без помилок то середовище Python тепер готове до роботи зі скриптами Mapillary Tools.

Розрахунок напрямку зйомки зображення з допомогою скриптів Python

Спочатку хочу сказати, що Mapillary Tools містить багато скриптів для обробки зображень та для завантаження на сервіс Mapillary, в тому числі і скрипт для прив’язки зображень до GPS координат, проте деякі з них не працюють або працюють неправильно, про що автор скриптів і написав у коментарях даних скриптів. Так наприклад мені не вдалося прив’язати зображення до GPS координат, тому я і описав два простіших способи раніше у статті. Але скрипт для визначення напряму зйомки шляхом інтерполяції в моєму випадку працює і швидко задає напрям зйомки фото у градусах базуючись на координатах наступного знімка в серії time-lapse. Отже, перейдемо до встановлення напрямку зйомки. На даному етапі у нас є тека зі знімками, які уже мають координати та часові мітки, тому все що нам потрібно це вказати шлях до скрипта, шлях до теки зі знімками та зміщення камери відносно напряму руху. Якщо камера напрямлена в напрямку руху, то зміщення буде “0” Скрипти знаходяться в папці python завантаженого раніше архіву Mapillary Tools. В моєму випадку шлях до скрипта “”, який нам потрібен наступний: “C:\Users\vfedo\Documents\Mapillary\mapillary_tools-master\python\” Шлях до теки зі знімками наступний: “D:\Mapillary\19.05.2016\backup” Далі запускаємо командний рядок та вводимо наступне: python “C:\Users\vfedo\Documents\Mapillary\mapillary_tools-master\python\” “D:\Mapillary\19.05.2016\backup” 0 interpolate_direction_script Після закінчення роботи скрипта отримали знімки з прив’язкою до GPS координат та напрямом зйомки, які готові до завантаження на сервіс Mapillary. Наглядно напрям знімків можна перевірити в програмі GeoSetter, просто обравши каталог зі знімками та переходячи між файлами стрілками клавіатури, це дозволить знайти знімки, які були оброблені не коректно скриптом, наприклад при простої перед світлофором точки GPS-треку будуть “танцювати” навколо вашої реальної позиції, тому і напрям знімків буде визначено помилково. Дану операцію можна виконати і через сервіс Mapillary, і це стосується саме послідовності знімків зроблених при русі на велосипеді/пішки/автомобілем, але обробка займає багато часу і мої знімки хоч і мають правильний кут в редакторі Mapillary, при перегляді все-одно напрямлені на північ (за замовчуванням) те ж саме при перегляді в JOSM, тому краще завантажувати повністю підготовлені знімки (з необхідними тегами: "GPSLongitude", "GPSLatitude", "DateTimeOriginal" та “GPSImgDirection”. Якщо ж зображення все-таки були завантажені без тега “GPSImgDirection”, це можна виправити. Для цього потрібно зайти в редактор зображень Mapillary та вибрати опції послідовності зображень, щоб кожне зображення орієнтувалося в напрямку позиції наступного зображення та виставити кут відхилення від напрямку руху, якщо камера була направлена не за напрямком руху. Відлік кута відхилення іде за часовою стрілкою в системі Північ-Схід в діапазоні від 0 до 359 градусів. Наприклад коли камера була напрямлена в ліве вікно автомобіля, то зміщення камери відносно напряму руху буде 270 градусів (або -90). При тестуванні три моїх послідовності знімків (1, 2, 3) були завантажені без належного тегу “GPSImgDirection” і хоча й була вибрана вищезгадана опція, знімки все-одно направлені на північ, як на сервісі так і в JOSM. Для завантаження на сервіс також є скрипти, але в даній статті буде розглянуто ручне завантаження через веб-браузер, так як буде видно чи правильно оброблені знімки.

Завантаження на Mapillary

Для завантаження на Mapillary спочатку потрібно створити обліковий запис на даному сервісі. Після успішної реєстрації заходимо на сторінку Mapillary та у правому верхньому кутку буде ім’я користувача вибране при реєстрації. Натиснувши на ім’я користувача можна налаштувати профіль користувача, перейти до профілю користувача та перейти до Ручних Завантажень. mapillary_user_profile Переходимо в розділ ручних завантажень, та натискаємо Вибір файлів (Choose Files), вибираємо зображення для завантаження після чого Mapillary перевіряє зображення: upload_dialog Якщо всі необхідні теги присутні, то ви побачите послідовність знімків з’єднаних лінією, кожне зображення матиме стрілочку яка вказує напрям: check_before_upload Далі тиснемо Відвантажити і чекаємо доки знімки передадуться на сервер Mapillary. press_upload Якщо під час відвантаження не змінюється відсоток відвантажених знімків, або ж обірвалося з’єднання з мережею інтернет, завантаження можна продовжити, натиснувши на посилання “Upload hung up? Click here.” upload_hung_up Сторінка оновиться і буде показано знімки, які уже відвантажені на сервер при цьому потрібно знову вибрати усі знімки, сервіс перевірить їх та відкине усі знімки, які уже відвантажено, та запропонує відвантажити знімки які лишилися, показавши їх положення на міні-карті оранжевими прапорцями. upload_more_photos_to_this_sequence Після завантаження всіх знімків, кількість у відвантаженій послідовності бажано звірити з кількістю файлів у каталозі зі знімками. Все правильно 646 знімків завантажено. Тепер можна натискати на кнопку Опублікувати послідовність (Publish Sequence) і отримуємо віртуальний “Дай п’ять” за гарну роботу. Тепер розберемося як використовувати дані з Mapillary для картографії OSM. publish_sequence

Використання сервісу Mapillary для картографії в OSM.

Так як дані з Mapillary можна використовувати для нанесення об’єктів OSM, то розглянемо як це можна зробити у двох найпопулярніших редакторах даних OSM, а саме JOSM та iD Editor.

Використання Mapillary в JOSM:

Для використання сервісу Mapillary в JOSM з можливістю відображення геотегованих зображень як шару, спочатку потрібно встановити однойменний втулок. Для цього заходимо в Налаштування JOSM (F12)>>вкладка Втулки>>в рядок пошуку вводимо Mapillary. Після встановлення втулка перезавантажте JOSM. install_mapillary_plugin Після запуску JOSM завантажуємо дані мапи з сервера OSM для ділянки де є покриття Mapillary. Покриття можна перевірити на веб-сторінці сервісу Mapillary, через пошук на інтерактивній карті, зеленим кольором зображені послідовності знімків. На жаль, на даний момент покриття є для частини обласних центрів України. mapillary_map_coverage Я завантажу область рідного смт, для якої я відвантажував геотеговані послідовності знімків. Після завантаження шару даних мапи OSM, шар знімків Mapillary можна завантажити з меню Фон>>Mapillary (або комбінацією клавіш Shift+comma). mapillary_in_josm

Використання Mapillary в iD Editor:

Для підключення шару Mapillary в iD Editor потрібно просто зайти в режим редагування обраної ділянки та натиснути на іконку меню Дані мапи (комбінація клавіш F) та обрати Фото-шар (Mapillary). Після цього з’явиться шар знімків Mapilary з напрямом та можливістю натискати на прапорець для фіксації зображення. mapillary_in_id_editor


Співпраця Mapillary та OSM має велике значення для обох проектів. Дане керівництво створювалось з метою надихнути спільноту OSM Україна на збільшення покриття Mapillary на території України, для заповнення прогалини Yandex Панорам, що доступні тільки для обласних центрів та міжнародних трас і дозвіл на використання яких для OSM, завжди може бути припиненим.

Посилання на мій профіль Mapillary та першу вдало створену послідовність фото.

Чудова gif-анімація була створена за допомогою open-source програми ScreenToGif.

Якщо помітили помилку в статті прошу повідомити.

Всім веселого та продуктивного мапінгу.

by Blackbird27 at May 20, 2016 08:41 PM

Google Summer of Code 2016

Improved Shaders for OSM2World

Read the proposal here.


My name is Zach, I'm a sophomore computer science student and research assistant at Southern Illinois University Edwardsville. I'm also a gamer, so when I saw the project suggestion I was excited to get the excuse to play with OpenGL and figure out how it works. I'd done some work with it in the past for 2D applications, but I haven't played with it in 3D. By the end of the summer I no doubt expect to have a firm grasp of it at the very least. Check out my github.

Getting set up

By default OSM2World doesn't use any textures, and has shadows disabled. There is an existing "texture pack" that contains the textures used to generate this map. My first step was tracking that down, its here (Basti sent it to me, so it wasn't actually that hard). To use it, the textures folder and properties file must be in the same directory as the built jar. After dumping those into my build folder, I was ready to go. I loaded up a map file and immediately crashed. I tried a few different map files until finally getting an empty parking lot to render, albeit with strange graphical issues. After crashing Java several more times, I moved from my underpowered laptop to my more powerful desktop computer (with an actual graphics card) and didn't have any problems from there. With this in mind, all of the changes that I plan to implement will be configurable so as not to make OSM2World unusable on a less powerful computer.

Shadows and Sunlight

I'd like to have the ability to change the time of day, many neat effects and images can be produced by moving the sun around and changing its color. I'm going to produce a small menu that lets you do just that, changing the time of day (or night) with a slider, and then calculating the appropriate angle and color of the sun and shadows. Passau


What I'm most excited about seeing is this picture. The second major component of my project is reflections. If this were a real image, you would see the reflection of the short building in the foreground on the front of the building behind it. On the right side of that same glass building, if the sun were in the right place, you would expect the shadow of the short building on the right to be illuminated by the sunlight reflecting off the glass on the tall building, potentially a glare hitting the camera. London

Other Stuff

If you want a full breakdown of what I plan to do, have a look at the proposal, it includes a handful of other things I didn't mention. If there's anything you want to see, feel free to leave a comment here, send me a message, or open an issue on github, but I can't promise anything until I get through the big stuff.

by Zabot at May 20, 2016 08:29 PM


Bristol (& New Brighton) Buildings from Lidar

West front of Bristol Cathedral
West Front, Bristol Cathedral
One of the buildings where we could use Lidar data to enhance its representation in OSM
At OpenData Camp 3 over the weekend I asked John Murray if he could give me a set of polylines extracted from the Environment Agency Lidar Open Data. Do read John's amazing post about the tools he has built for doing nifty things with Lidar data: Turning Lidar Data into Actionable Insight.

I thought if might be a bit of fun to actually show directly how opendata produced by one of the ODCamp sponsors might end up in OpenStreetMap.

In practice John got keen over the lunch break and wrote a bit of code to turn his polylines into polygons. So just before the last session of the day kicked off I had been sent a shape file for the 1km Ordnance Survey gird square where the meeting was taking place.

We had one initial teething problem that the data was out by 1 km, but notwithstanding that it was very simple to perform some simple manipulations in the off-line OpenStreetMap editor JOSM.

JOSM can read shapefles (and some other geo-formats such as geojson too) and automatically transforms these into OSM elements projected in WGS84. Therefore the additional data manipulation steps were pretty trivial:
  • Select all way elements (using a type:way search)
  • Add a source=EA Lidar Open Data tag
  • Select all type:relation elements to find multipolygons
  • Add building=yes tag
  • Select all way elements which were not part of multipolgons (type:way and not child type:relation)
  • Add building=yes tag
  • Select all way elements again and simplify them.
 The image below shows how this looks in the editor

Now this is all pretty amazing, and if you read John's blog post there's lot more info which can be gleaned. However a close inspection of the data still shows a sizeable number of artefacts which would need cleaning up. Some John has dealt with in the intervening few days, but turning any automatically extracted feature into something of the sort of quality which can be one in OSM is another matter: and is not too dissimilar to the points I made some time ago about OpenMap Local.

For me the real advantage is that it's a major step in making if more feasible to use Lidar data to enrich OSM data. For instance data on roof orientations could be combined with the algorithms & crowd-sourced validation methods from OpenSolarMap. I hadn't realised until listening to John's talk just how valuable gable or eaves heights are in building datasets. It certainly persuaded me that they belong in OSM.

Another downside is that it takes a whiz like John to create this software and it makes use of a powerful machine, powerful algorithms, optimised hardware & proprietary storage. I have therefore spent a little time this week looking again at what is available in QGIS to do similar (but much less powerful) manipulation of the Lidar data.

Basic transformations of Lidar have been described elsewhere (for instance see Chris Hill's posts) so I won't dwell on them here. Suffice it to say I presume that the following have been created for a given area:
  • Combined Digital Surface Model (DSM). I usually do this as a virtual time set (can be done directly in QGIS)
  • Combined Digital Terrain Model (DTM). As above.
  • Delta of the two. DSM-DTM. This gives things (buildings, cars, trees etc) which are elevated above ground level.
To get somewhere near what John's approach involves ideally requires:
  • Filtering out shorter objects (mainly cars, garages & some street furniture)
  • Filtering out smaller objects (mainly trees)
  • Edge detection
  • Polygonisation
In practice I found it relatively easy to do the first & last and did not find a simple way of doing the other 2 in QGIS (although in part that might be because I'm short of disk right now).

The other two can be achieved easily:
  • Filtering by Height: this is merely another raster calculation using the QGIS Raster Calculator. In my test area (New Brighton on the Wirral, OS grid ref SJ3093) most houses are Edwardian and much higher than 3 metres, whereas garages are usually a touch over 2 metres. I therefore used 3 metres as a cut-off.
  • Polygonisation. I used the height filtered data directly with the Raster...Conversion...Polygonize option in QGIS. This is a much cruder and more naive method than I was hoping to use, but there it is.
I show the results of these steps below (in separate images to allow easier inspection & then combined).

Lidar Height data (DSM-DTM) filtered for >3m

Extracted & OSM Building polygons compared
(garages are deliberately excluded from OSM data)
Height data combined with Polygons

Firstly it's worth noticing a few features from the raw height data:
  • Most buildings are tall, usually in excess of 8 metres (and probably at least that height at the gables).
  • There are a limited number of lower height buildings. The most obvious ones are near the top of the image and include two small factory premises N of the railway & the platform canopy of the railway station. S of these the road bridge over the railway is obvious; and immediately to the SE there are apparently two largish buildings of low height, albeit quite a bit of noise in the height profile. (These are, in fact, Victoria View a development of flats which halted for several years). Further S still there are a small number of bungalows.
  • Terraces with a lower rear service area are obvious.
  • There are a significant number of linear features above 3 m in height. Most look to be walls, and indeed garden walls in the area tend to be high as most gardens are small & given building heights would tend to be overlooked.
  • Isolated trees are obvious in one or two back gardens
  • Larger groups of trees are equally obvious along the railway line (& elsewhere)
  • Swirly patterns in the 3-4 metre range occur in a number of places. These are mainly scrub (mainly gorse) or shrubberies.
  • There are still parked vehicles giving returns in the 3-4 metre height range. 

Edwardian Streets S of Mount Road New Brighton (Dovedale & Langdale Rds)

I include a couple of photos of streets in the area to help with context. I would recommend strongly Russ Oakes' work documenting suburban streets all over Merseyside for a much broader perspective.
Junction of Dudley & Hamilton Roads, New Brighton

Comparing the extracted polygons with OSM (and ignoring some OSM data which is missing) shows:
  • There is a fairly constant offset of OSM data (presumably inherited from the Bing imagery).
  • Building footprints are broadly comparable
  • Small gaps in terraces are resolve much better by tracing.
  • Some detail has not been added to some of the terraces in OSM which are still drawn as plain rectangles.
  • It's certainly possible to spot missing features & use Lidar data as an aid to add them in (notably Victoria View, but the W part of the development was started after the Lidar data.
Now as for deriving data to enhance OSM there's a fair more bit of processing needed.

Absolute building height is relatively easy, one just needs to find the maximum height within a (location corrected) OSM polygon. Generating the other more useful Simple 3D building (S3DB) tags is rather more involved, and certainly I have the impression that QGIS would be a fairly clunky way to do things. I really hope that some more technically-minded OSM folk can take inspiration from John's ideas and start thinking about tools to mainpulate Lidar data specifically for OSM.

There is no doubt that the Environment Agency Lidar data was one of the most significant open data releases last year. Furthermore it is likely that other agencies & local government bodies will make Lidar available more widely in the near future. For instance I believe much data from Kanton Zurich is open, including Lidar. This example shows the extensive slumping caused by peri- and post-glacial phenomena in the woods near Bergietikon: so this is a reminder that it's not just buildings which are of interest.

One last thing to note is that there's lots one can do with this data immediately (the subject of John's original article). Working how to add this data to OSM begins to look not dissimilar to creating authoritative datasets. It's of course worth spending time working out how to do this because once in OSM the data is potentially available for a multitude of purposes.

by (SK53-osm) at May 20, 2016 04:42 PM

" User's Diaries"


today i ,made a bar and mapped 2 houses as well as make a bank and other things. this was really fun but i'm tired of it so i'm writing in this diary entry. it is super fun to type, more funner than making maps. YYAYY! we are taking a group picture, i'm so ready to rock it. the lady is so AWESOME shes going to the white house and she may meet Barack Obama! im so excited.

by Esther Nellameli at May 20, 2016 03:45 PM

Adção de clínicas

Adição de clínicas de Otorrinolaringologia. Percebi que várias clínicas ainda não estão no mapa. Justamente quando procurei por uma. Então iniciarei o mapeamento delas.

by Marcos_BR at May 20, 2016 02:58 PM

Pascal Neis

Verified OpenStreetMap contributor profiles?

The reputation of a contributor in OpenStreetMap (OSM) plays a significant role, especially when considering the quality assessment of the collected data. Sometimes it’s difficult to make a meaningful statement about a contributor by simply looking at the raw mapping work represented by the number of created objects or used tags. Therefore, it would be really helpful if we would have some additional information about the person who contributes to the project. For example: Does she/he help other contributors? Is her/his work somehow documented or based on one of the “discussed” proposals? Or does she/he work as a lone warrior in the OSM world?

In 2010 I created “How did you contribute to OpenStreetMap?” (HDYC) as a kind of fun side project. Nowadays many people use it to get some detailed information about OSM contributors. Some of you are probably familiar with the “verified” icon used on some celebrity Twitter accounts. I created a similar new feature for the aforementioned HDYC page. If you connect your related OSM accounts, your profile will be marked as “verified”.


What do you have to do to get a verified contributor profile, you ask? First of all, you have to create at least 100 OSM changesets. Secondly, you need a login (username) for the OSM Help Forum, for the common OSM Forum and for the OSM Wiki. Last but not least, you have to list your OSM related accounts on your OSM profile page. After that, you should be able to see your accounts in your HDYC profile and your account will be automatically marked as verified.

Malenki already mentioned his usernames as an example in his profile. He also described it in a tiny OSM diary. Overall this feature is optional. So if you don’t want to “connect” or show your accounts for privacy protection, please don’t mention them on your OSM profile. My script checks the OSM profiles of the latest active OSM contributors every 24h. That’s it.

The HDYC profile now also shows the number of your changeset discussions and, if mentioned in your OSM profile, the page shows your Mapillary account as well.

Notice: If someone is trying to cheat with other people’s accounts, I will blacklist her/his username.

Thanks to maɪˈæmɪ Dennis.

by Pascal Neis at May 20, 2016 02:50 PM

" User's Diaries"

MapillaryJS is now supporting tagging

Hi there, I just wanted to point out that for the next step in providing high quality data to OSM, we at Mapillary are preparing to close the feedback loop for the algorithms not only on the mapillary site with blurring etc, but for potentially all other objects like street signs (more to come). You can soon tag things as points and rectangles in MapillaryJS, thus providing feedback on things that are good or bad, and even tag things yourself that you need in your own data, all in the 3D visual environment of MapillaryJS.

There also is a pull request pending for getting MapilaryJS to show up in iD for better visuals than the existing static images to start with so stay tuned!


by Peter Neubauer at May 20, 2016 07:07 AM




 * (#) のあとに半角あけて文字を打ち込む

 * 文字が青くなったら正しく表示される


 * (*)の後に半角あけて文字を打ち込む

by chinmo at May 20, 2016 06:27 AM

5/20 メモ



  • # 見出し
  • ## 見出し2
  • ###見だし3

  • * 内容

by 有松_15 at May 20, 2016 06:27 AM

5/20 メモ


  • # 見出し
  • ## 見出し2
  • ###見だし3

  • * 内容

by 有松_15 at May 20, 2016 06:26 AM




  • # (シャープ)を半角で記入して、半角のスペースを入れた後文字を入力する。
  • 小見出しの場合は##と二つにする。


  • *(アスタリスク)を半角で記入して、半角のスペースを入れた後文字を入力する。

by hyakuda miyu at May 20, 2016 06:25 AM




  • 見出しは#、小見出しは##、項目は*を使うよ慶晃

by yoshipons at May 20, 2016 06:24 AM




  • 見出し #(半角シャープ)を入力し、半角スペースを空けて、見出しの内容を書き込む。##を使うと、小見出しになる。
  • 箇条書き *(半角アスタリスク)を入力し、半角スペースを空けて、内容を書き込む。

by nanakonako at May 20, 2016 06:24 AM




  • 「# 」(シャープと半角スペース)のあとに見出し
  • 本文を入力


  • 「## 」のあとに小見出し
  • 本文を入力


  • 「* 」(アスタリスクと半角スペース)のあとに内容
  • 繰り返す

by ymdrs at May 20, 2016 06:24 AM



## 見出しの書き方  * ♯(シャープ)を使い半角で入力し、#のあとは半角1スペース空けたあと、見出しを入力する。

## 箇条書きの書き方 * アスタリスク()を半角で入力し、のあとは半角1スペース空けたあと、箇条書きをはじめる。

by hf_1d at May 20, 2016 06:23 AM




  • 見出しの前に半角#と半角スペースを続けて入力
  • 複数の階層構造を持つ場合、#の数を増やす


  • 本文の前に半角*と半角スペースを続けて入力
  • 箇条書きが複数に渡る場合必要に応じて改行すること

by hikari_N at May 20, 2016 06:22 AM



## 見出しの書き方  * ♯(シャープ)を使い半角で入力し、#のあとは半角1スペース空けたあと、見出しを入力する。 ## 箇条書きの書き方 * アスタリスク()を半角で入力し、のあとは半角1スペース空けたあと、箇条書きをはじめる。

by hf_1d at May 20, 2016 06:22 AM



  • 見出しの場合は半角# + 半角スペース
  • 箇条書きの場合は*(アスタリスク) + 半角スペース

by watta- at May 20, 2016 06:22 AM




  • Internet Explorer は使用禁止
  • マイクロソフトの Wordファイル(doc/docx)で提出してはいけない
  • 原則文書の提出は Markdown 記法でテキストファイルで提出
  • 特別な理由がない限り MSゴシック/MS P ゴシックのフォント使用禁止



  • 半角#+半角スペースで見出しを作成
  • 半角#を重ねることで項を作成することができる


  • 半角*+半角スペースで箇条書きを作成

by hnmt at May 20, 2016 06:22 AM




  • #(半角)スペース(半角)でそのあとに見出しをかける。小見出しが欲しい場合は#の数を増やす。


  • *(半角)スペース(半角)で箇条書きになる。

by 870 at May 20, 2016 06:21 AM

2016 0520 Markdownの書き方

見出しの書き方  1、 半角の”#_”(シャープ+空白)で書くと  : # 見出し 

箇条書きの書き方  2、 半角の”*_”(アスタリスク+空白)で書くと  : * 箇条書き

by yan53074 at May 20, 2016 06:21 AM


# Markdownの書き方 ## 使う記号 * 見出しは#、小見出しは##、項目は*を使うよ慶晃

by yoshipons at May 20, 2016 06:21 AM

05/20(金) ネットワーク markdown の使い方

見出し  → (# )


  • 箇条書き  →(* )

インターネットエクスプローラー使わない ワード形式で提出は認められない。 ⇒Markdown形式で提出


by みりん at May 20, 2016 06:21 AM




  • 半角の#(シャープ)の後に半角スペースを入れる。
  • 全角だと反応しない


  • 半角の*(アスタリスク)の後に半角のスペースを入れる。

by takahirofukuyama at May 20, 2016 06:20 AM




  • 半角#の後に半角スペース
  • #を重ねることで階層表現


  • 半角*の後に半角スペース

by vaitu at May 20, 2016 06:20 AM




  • #_ :見出し
  • ##_:小見出し
  • *_ :箇条書き


by frsho at May 20, 2016 06:20 AM



  • 見出しは半角の#と半角スペース
  • 箇条書きは半角の✳︎と半角スペース

by yuuukaaaa at May 20, 2016 06:20 AM

May 19, 2016

Russion live OSM radio

" User's Diaries"

TIL about OSRM debug map

A set of turns bypassing a roundabout I reconfigured recently was disliked by OSRM, instead sending the cars via the actual roundabout:

Take the roundabout

Daniel Patterson @ OSRM #2421 directed me towards a debug OSRM map showing that the roundabout links without ''maxspeed'' tag were categorized with default speeds of ~25 km/h (~16 mph) while the roundabout tagged with 20 mph (32 km/h) provided a faster way.

OSRM Debug

So, take a look at if OSRM seems to ignore a better route.

by ryebread at May 19, 2016 08:00 PM

Украина и Крым после декоммунизации или что делать после переименования?

Города после внесения правок Здравствуйте!

Заметил, что не прошло и половины дня, после принятия Верховной Радой Украины закона о переименовании 150 населённых пунктов в Украине в рамках декоммунизации, как некоторые пользователи поспешили переписать название городов и других населённых пунктов. В целом поддерживаю саму инициативу переименования, за исключением ряда городов, но это не относится к делу. Города после внесения правок Два вопроса по существу к украинскому и русскому сообществам:

  1. Некоторые города в разных слоях отображаются как Днiпро и Днiпропетровськ, Кам`яньске и Днiпродзержинськ одновременно. В чём причины и как этого избежать?
  2. Переименование населенных пунктов в Крыму. Что делать с этим?

В отличие, от Яндекс Карт, OSM не может иметь две разных карты одновременно. Спустя какое-то время данные попадут в те же MapBox, API Одноклассников, Вконтакте, других онлайн проектов. Например, в и других сервисах, где карты вообще оффлайн, может возникнуть путаница на месте с ориентировкой.

Есть ли какие-то рекомендации глобального сообщества по таким спорным вопросам или всё на усмотрение модераторов?

by JaromirJagr at May 19, 2016 05:55 PM


Всем привет!

Хотел бы напомнить про важность отмечания тротуаров в городе. Особенно вдоль улиц с односторонним движением. Если они не отмечены OSRM, и другие навигационные системы роутят пешеходов и велосипедистов по длинным и далеко не оптимальным маршрутам. Так что не стесняйтесь добавлять вдоль улиц дорожки, отмечая их highway=footway + footway=sidewalk (разумеется там где они действительно есть).

Вместе мы сделаем лучшую карту в мире!

by ghost_07 at May 19, 2016 05:00 PM

The importance of sidewalks

Hi all,

I can see a lot of places on the map in the cities, where there are one way roads, but no sidewalks set. That leads to incorrect pedestrian and bicycle routing in, osrm, and other navigational software. So please, don't hesitate drawing ways marked as highway=footway + footway=sidewalk along streets (of course where sidewalks actually exist). I already started doing it in russian cities Moscow and Tula.

Together we'll create the best map!


by ghost_07 at May 19, 2016 04:44 PM

Missing Maps Post-Ebola Border Mapping Project

Missing Maps is currently engaged in motorcycle mapping of the entire border regions between Sierra Leone, Liberia, and Guinea. Here is an excerpt from my trip report from the first recruiting and training mission to Sierra Leone. Trip Report - Phase One




Training of Field Team Leaders in preparation for recruiting Volunnteer enumerators and performing Sierra Leone Mapping Project

Aims and Objectives:

As MSF consultant, deployed for the training of pre-recruited Field Team Leaders for the Missing Maps Border Project this training was designed to prepare FTLs for Volunteer Recruitment, to initiate the survey project, and to establish possible links and contacts by which to implement the phase two return visit. Prior to the trip, an important part of the project became the establishment of definitions of admin levels which could bring data-sets usefully in-line with those gathered in the Liberia and Guinea. Using FTL feedback,necessary adjustments were made in the field in order to leave a workable community survey prototype survey form as a guide for recruiting and training.

Day 1 (Wednesday, 4th May)

Red Cross Introductions (Abridged due to time constraints) Hand-over to Rupert Presentation: Missing Maps Introduction (the global picture) Descriptions and locations using and evaluating map-reading skills ('Where am I from?') Introductions to Smart Phones, Presentation two and Introduction to ODK Introduction to OSMAND and tracking Study Of Maps, Home Address and Admin Levels, and FTL Introduction to their 'Territory' Subsequent Discussion of Area Coverage for each FTL, and Personal Field Survey Boundaries to be completed as homework Discussion of Missing Sections in Survey and Listings, to be completed as homework

Day 2 (Thursday, 5th May)

Group Presentation of Survey areas, and work plan concept. ODK forms, and initial data-collection of Red Cross Moto, Locations and Guesthouse forms Demonstration of form after modification, and tweaking Recruiting Volunteers, Refresher on ODK – Group Work, evaluation, and commentary Connectivity, Uploading and Servers Demonstration with Edison ODK Aggregate Local Community visits – into 'Slum' Area (counter-productive to some extent because of orchestration of community meeting, but valuable nevertheless) Ad-hoc surveys taken on return from 'Slum' Surveys – much more useful as an exercise. Round-up and Close

Day 3 (Friday, 6th May)

Review forms and techniques Head out to rural area (This was too far away, and took up valuable classroom time. We finally did our first survey at 1230hrs, having called candidates for 0730hrs!) Demo Interview with Community Head Split off into groups around community Re-convene, evaluation, good feedback on 'close-down/termination of interview' work-arounds. Road/Travel barrier survey on return (Photo Option Used) Travel Back, and Debrief More Practise Sessions and Q&A about field Prep Red Cross Briefing on Branch Officer/Local Protocols Random Tutorials (e.g. Phone Tethering, Wireless Hotspots, Tech Hardware Interface) Course Feedback End


Course feedback was very good, which was satisfying. The prep-time allowed me by the delays proved to have been well-used, and I was extremely encouraged by the week's progress. I have high hopes for the FTLs, who are already demonstrating initiative, creativity, dedication and commitment. The WhatsApp group I have set up is well-used, and serves as a Log of Activity, as well as a meeting point across cultures and job-roles. Overall, it was soon realised that ability and capacity amongst FTLs was probably better that those recruited in both Guinea and Liberia. FTL selection was probably easy, as it was clearly done on the basis of Red Cross members who had been in Community Outreach (Mobilisation) and Logging (Data-Collection) during the Ebola Outbreak period. FTLs had used Android-based apps before for the implementation of the 'Safe and Dignified Burial' Program, and were familiar with ODK-style interface, due to some familiarity with 'Magpie'.

Motivation and project ownership were seen as important for the development of good practice, and I attempted to engage the candidates in some advanced activities such as Data Submission, Device Optimisation, and Form-Building Admin/Div discussion.

As a result of this, I am confident that the current prototype form deals with admin levels effectively, as I was able to adjust and trial the questions with the FTLs during field trainings, adjusting in the evenings. I saw this as a great achievement of our training week, a week which was punctuated with stark reminders of what the FTLs and their communities had been through in their battle against the terrifying Ebola disaster.

Technical Report:

The Public holiday issue was worked-around. Generator: Sometimes and issue, as always, in class. MSF overnight charging and internet was an issue. (Generator in MSF House off between 0000hrs and 0600hrs.) Projectors were used in tandem – one for presentation, the other for phone demonstration. The method of linking it with my Sony Experia Z1 was very very useful for teaching. I benefitted from my own personal investment of two Experias. (we couldn't figure out the Blu Phone interface, but only because we were rushing) I bought some cheap USB 12v - 5v chargers from the 'Pound Shop' in London, which I gave to the FTLs in their packs to trial on the motorbike batteries. I am awaiting feedback. Each FTL was given a pack of stationery, a set of maps (waterproof ink on plain paper, for annotation-capacity), and a waterproof Map-Tube. I also gave them each a backup USB with all classroom and form versions on, after careful consideration of their technical abilities. I will use their responsible use of these to evaluate further delegations of equipment, tools and skills during phase two.


In conjunction with agreed initial Red Cross terms of reference, I am recommending that we maintain our initial plan to reconvene with our Field Team Leaders on 30th May for a de-briefing day or two.

Subject to adjustments from the Hub and/or American Red Cross, we then meet with all of the volunteers gathered, and enter the selection process of shortlisting and Field Training during the week leading up to Friday June 3rd.

It was agreed that volunteers recruited by the FTLs would number approximately twice the number needed (i.e. sixty). These volunteers will need to be brought to the capital, housed, and those not selected compensated and returned. The remaining selected will then need to be housed and provided-for for the rest of the week.

On Saturday 4th June, all those participating will need to be transported back to trainings in regional areas, in which MSF trainers Pete Masters, Nick Allen, and Rupert Allan will provide field-support across the districts, individually based in Kenema and Kambia MSF facilities. It should be noted that extra support will almost certainly need to be given to the Bombali District, where it feels as if we are short-staffed. FTLs Mohamed and Sulaiman are attempting to combine coverage of this area between themselves. It may be that requests are made for extra volunteers.

Here is some video footage of Red Cross reportage on Sierra Leone's Northern Border in Kambia District: [Kambia Border Challenges][]

by rupertmaesglas at May 19, 2016 03:29 PM

OpenStreetMap Weekly Update

weeklyOSM 304


The “Import Project INEGI National Geostatistical Framework” finished [1] | go to the blogl


  • The German forum started a large discussion about bi-lingual names in Sorben (Germany) (automatic translation).
  • Mapbox extends its geocoder by supporting of Wikidata information.
  • Martijn van Exel descibes updates to ImproveOSM JOSM plugin for better usability.
  • The planned server outage and the relocation of the OSM servers lead to slow upload speeds and downtimes of the wiki server. As of now, everything is expected to return to normal.


  • The OpenCage Data blog interviews Laura Barroso (an active member of weeklyOSM and the woman in charge of the Spanish edition) about OSM in Cuba.
  • Presentation of the Importation Project: MGN (National Geostatistical Framework) of INEGI in Mexico by members of Telenav: Miriam Gonzalez and Andres Ortiz. Read more here.
  • In his series Mapper in the Spotlight, Escada interviewed Pete Masters from Scotland, a pioneer of Missing Maps.
  • Johnattan Rupire informed weeklyOSM about a professionally made video showing many aspects of OSM. Subtitles are availabe in French and English.


  • Andy Townsend published on the import mailing list a communication by Kate Learmonth (UNICEF Office of the Pacific Iceland Countries) with the DWG for imports after cyclone Winston on the Fiji Islands.

OpenStreetMap Foundation

  • The OpenStreetMap Foundation is hiring an administrative assistant. Applications can be sent in until June 3rd.


  • SotM 2016 Brüssel – important date Saturday May 21st
  • The SotM US program is online.
  • The 6th International Conference on Cartography & GIS will be held on 13th-17th of June 2016 in Albena, Bulgaria.
  • On 10th – 12th June 2016 the Geocaching GIGA-Event Project Glück Auf 2016 will be held at UNESCO’s World Heritage Zollverein. More than 10000 Geocachers are expected to join the event that features many workshops and guided tours.
  • A report to this year’s FOSS4G NA in Raleigh, NC, USA. Interesting is the communication on the Portable OSM (portable OSM server) for mobile-use in disaster areas. Read more here.

Humanitarian OSM

  • HOT is activating to map for support of the relief efforts in Sri Lanka. The first task is already up.
  • Blake Girardot compiles a list of suggestions for improvements to OSM web editor iD. The goal is to help satisfy the needs of the HOT and Missing Maps communities. He is asking for input from the community.
  • Missing Maps in London decided to put more focus on using JOSM.
  • Aline Rosset from the University of Central Asia reported, in a guest post, about “OSM workshops with teachers and high school children of 10 rural villages in Kyrgyzstan” to map the Tien Shan mountains.
  • Blake Girardot searches for an expert in admin boundaries and OSM relations for helping to synchronize data and possibly importing it to OSM.


  • MapContrib is a site similar to uMap that allows a simple generating of your own map. Example maps include fire hydrants, mail boxes andr bicycle parking.
  • Laura Barroso, the weeklyOSM correspondent in Cuba, built the app MapaDCuba for her employer (we reported here). The app is rated recently as the best Cuban map app by a blogger in Cuba, but read it yourself.

Open Data

  • Geolode is a catalog to collect open geodata around the world.


  • Aleks Buczkowski from Geoawesomeness explains the legal situations with maps when published on the web.
  • Tarun Vijay, member of the Indian government got interviewed by The Wire about the new draft bill regarding map data. The Times of India publishes a portrait of Mumbai regarding this topic.


  • TrailBehind publishes DeepOSM, a deep learning net to use satellite imagery and OpenStreetMap data to learn classify and to detect features in imagery.
  • Mapzen’s routing software Valhalla now offers multi-modal public transport routing. A blog post introduces the product (for customers), a second blog post explains the technical background.
  • Tom MacWright explains why CartoCSS is defective and how it’s successor is much better for creating maps.


Software Version Release Date Comment
PostgreSQL 9.5.3 ff 2016-05-12 Update releases fixing a number of issues
Mapillary for iOS 4.3.1 2016-05-15 Added Portuguese and Estonian, added descriptions for new users
Locus Map Free 3.17.0 2016-05-16 Offline search of addresses and more

provided by the OSM Software Watchlist

Did you know …

Other “geo” things

  • Google adds new features and detailed maps of the venues to Google Maps to catch up with OpenStreetMap for the 2016 Olympic Games in Rio.

Upcoming Events

Where What When Country
Milano ”’State of the Map Italy 2016”’ 20.05.2016-21.05.2016 italy
Rapperswil 7. Micro Mapping Party 20.05.2016 switzerland
Clermont-Ferrand ”’State of the Map France 2016”’ 20.05.2016-22.05.2016 france
Los Angeles L.A. County building import mapathon 21.05.2016 united states
Sax Sax (Alicante) – micro Mapping Party 21.05.2016 spain
Brno ”’State of the Map CZ+SK 2016”’ 21.05.2016 czech republic
Clermont-Ferrand Missing Maps mapathon at SOTM France 2016 22.05.2016 france
Grenoble Rencontre mensuelle mappeurs 23.05.2016 france
Graz Stammtisch 23.05.2016 austria
Toulouse Missing Maps mapathon in Toulouse 24.05.2016 france
Derby Derby 24.05.2016 united kingdom
Cusco Semana de Accesibilidad Cusco 2016 25.05.2016 peru
Mantova 2016 Mapping party a Volta mantovana 04.06.2016 italy
Brussels Missing Maps Mapathon @Doctors without borders/Handicap international 06.06.2016 belgium
Trentino Besenello @ library 14:00. With support of Portobeseno and the Besenello Municipality 11.06.2016 italy
Edinburgh Edinburgh 14.06.2016 united kingdom
Lyon Rencontre mensuelle mappeurs 14.06.2016 france
Nottingham Nottingham 21.06.2016 united kingdom
Rapperswil Swiss PG Day 2016 24.06.2016 switzerland
Salzburg ”’FOSSGIS 2016”’ 04.07.2016-06.07.2016 austria
Salzburg AGIT 2016 06.07.2016-08.07.2016 austria
Seattle ”’State of The Map US 2016”’ 23.07.2016-25.07.2016 united states
Bonn FOSS4G 2016 Code Sprint 20.08.2016-22.08.2016 germany
Bonn Workshops at FOSS4G 2016 22.08.2016-23.08.2016 germany
Derby Derby 23.08.2016 united kingdom
Bonn ”’FOSS4G 2016”’ 24.08.2016-26.08.2016 germany
Bonn FOSS4G 2016 Code Sprint Part II 27.08.2016-28.08.2016 germany
Brussels ”’State of the Map 2016”’ 23.09.2016-26.09.2016 belgium
Metro Manila ”’State of the Map Asia”’ 01.10.2016-02.10.2016 philippines
Berlin Hack Weekend 15.10.2016-16.10.2016 germany
Karlsruhe Hack Weekend 29.10.2016-30.10.2016 germany

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropiate..

This weekly was produced by Hakuch, Laura Barroso, Peda, Rogehm, derFred, jinalfoflia, mgehling, wambacher, widedangel.

by weeklyteam at May 19, 2016 01:57 PM

OSMBlog (German)

Wochennotiz Nr. 304


Der INEGI MGN Import in Mexiko ist abgeschlossen [1] | direkt zum automatisch übersetzten Artikel


  • Die Diskussion um zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden wurde von Frederik Ramm wiederbelebt. (via @timetabling)
  • Marek mappt den Kölner Dom in 3D und beschreibt sein Vorgehen im Wiki. Auch für das Roof modelling hat er neue Ideen.
  • Mapbox erweitert seinen Geocoder durch Unterstützung von Wikidata-Informationen.
  • Martijn van Exel beschreibt die Änderungen am ImproveOSM-Plugin für JOSM, die eine bessere Bedienbarkeit erlauben sollen.
  • Die geplanten Wartungsarbeiten und der Umzug der OSM Servern führten zu langsamen Uploads und Wikiausfällen. Mittlerweile müssten aber alle Probleme beseitigt sein.


  • [1] Miriam Gonzalez berichtet über den INEGI MGN Import in Mexiko, der auch in Deutschland für Diskussionen gesorgt hatte. (automatische Übersetzung)
  • In der Reihe Mapper in the Spotlight wurde diese Woche Pete Masters aus Schottland interviewt, ein Pionier in Sachen Missing Maps.
  • Im Blog von Büro 2.0 hat Lars Lingner die Ergebnisse des Berliner Hackweekends von Ende April zusammengefasst.
  • Die peruanische Community hat ein professionell gemachtes Video, das viele Themen rund um OSM behandelt, ins Netz gestellt. Untertitel sind bereits in englisch und französisch vorhanden.
  • ..>”">..>”">Das OpenCage Data Blog interviewt Laura Barroso (eine aktiv Mitwirkende von weeklyOSM und die Hauptverantwortliche für die spanische Ausgabe) über OSM und Kuba.


  • Andy Townsend veröffentlicht auf der Import Mailingliste die Kommunikation von Kate Learmonth (UNICEF Office of the Pacific Island Countries) mit der DWG zum Import nach dem Wirbelsturm Winston auf den Fiji Inseln. Beachte auch die Schieber bei den Bildern zum Wirbelsturm.

OpenStreetMap Foundation

  • Die OpenStreetMap-Foundation sucht eine Teilzeitkraft für Verwaltungsarbeiten. Bewerbungen können bis zum 03.06. eingereicht werden.


  • SotM 2016 Brüssel – wichtiger Termin: bis Samstag, den 21. Mai¹
  • Das Programm der SotM US ist online.
  • Vom 13.-17. Juni findet die 6. Internationale Conference on Cartography & GIS (6ICC&GIS) in Albena (Bulgarien) statt.
  • Vom 10. bis 12. Juni 2016 findet das Geocaching GIGA-Event Projekt Glück Auf 2016 auf der Zeche Zollverein in Essen im Ruhrgebiet statt. Es werden über 10000 Geocacher erwartet mit bekannten Gesichtern, Workshops und Führungen auf dem Gelände.
  • Ein Bericht zur diesjährigen FOSS4G NA, Anfang Mai in Raleigh, NC, USA.
    Hervorzuheben ist die Mitteilung über den POSM (tragbarer OSM-Server) für den mobilen Einsatz in Katastrophengebieten. (automatische Übersetzung) Näheres auf Github.

Humanitarian OSM

  • HOT bittet um Unterstützung der Hilfsmaßnahmen bei der Flut in Sri Lanka. Der erste Task ist online. (Nach Redaktionsschluß wegen Aktualtiät aufgenommen!)
  • Blake Girardot erstellt für HOT eine Liste von Änderungswünschen für den Editor iD, die das Mappen für HOT und Missing Maps vereinfachen würden, und bittet dafür um Input.
  • Missing Maps (London) hat sich entschieden, vermehrt JOSM als Editor der Wahl einzusetzen.
  • Aline Rosset und Felix Delattre berichten für HOT über zwei 3-tägige OSM-Mapping Workshops mit Studenten in Kirgisistan, Zentralasien.
  • Blake Girardot sucht für HOT jemanden, der sich sehr gut mit Grenzen und Relationen in OSM auskennt und bei einem Datenabgleich und späteren potentiellen Importen helfen könnte.


  • MapContrib ist eine Seite ähnlich uMap, die das einfache Erstellen eigener Karten erlaubt. Beispielkarten mit Feuerhydranten, Briefkästen oder Fahrradparkplätzen.
  • Laura Barroso, die Korrespondentin der Wochennotiz in Kuba, hat für ihren Arbeitgeber die APP MapaDCuba gebaut. (Wir berichteten). Nun wurde die App von einem kubanischen Blogger als beste App für das Land bewertet. Aber lies selbst.


  • Open Government Wien stellt eine Umfrage vor, die Open-Data-Geschichten sammelt und diese in Zusammenarbeit mit den Autoren veröffentlichen möchte.
  • Geolode ist eine Webseite, die versucht, einen Katalog offener Geodaten weltweit zu erstellen.
  • Gordon Haff assoziiert in|business die Begriffe “Offen” mit “Quelle” und gibt seine Gedanken preis über die Zusammhänge von Open Data, auch der OSM, speziell in USA.


  • Aleks Buczkowski erklärt auf Geoawesomeness die rechtliche Situation zum Copyright von Karten, wenn man diese im Netz veröffentlichen will.
  • Tarun Vijay, Mitglied der indischen Regierung, wird von The Wire zum neuen Gesetzesentwurf interviewt (wir berichteten). Die Times of India veröffentlicht ein Porträt von Mumbai zum Thema.


  • TrailBehind veröffentlicht mit DeepOSM Code, der anhand von Satellitenbildern und OpenStreetMap-Daten durch Deeplearning-Techniken lernt, Bilddaten zu klassifizieren und Features zu erkennen.
  • Mapzens Routingsoftware Valhalla bietet jetzt auch multimodales ÖPNV-Routing an. Ein Blogpost stellt das Produkt (für die Kundschaft) vor, ein zweiter erläutert die technischen Hintergründe.
  • Tom MacWright von Mapbox erklärt, warum CartoCSS eigentlich unbrauchbar ist und warum ein Nachfolgeprodukt (natürlich von Mapbox) wesentlich besser geeignet sein soll.


Software Version Release Datum Änderungen
PostgreSQL 9.5.3 ff 12.5.2016 Update Releases mit wichtigen Korrekturen einiger Probleme
Mapillary für iOS 4.3.1 15.5.2016 Unterstützung für Portugiesisch und Estnisch, erweiterte Doku für Newbies
Locus Map Free 3.17.0 16.5.2016 Offline Adresssuche und mehr

bereitgestellt von der OSM Software Watchlist

Kennst du schon …

  • … die Faszination der verworrenen Spaghetti Junction? Kristin Hohenadel stellt die Arbeiten des Künstlers Nicholas Rougeux vor, der OSM-Daten von Autobahnen in künstlerische Werke umsetzt.
  • … das “Garten-Engagement” der USDA? Das U.S. Department of Agriculture sucht im gesamten USA-Raum nach besonderen Gärten aller Art, um diese auf einer (OSM-basierten) Karte vorzustellen. Die Art der Gärten kann gefiltert werden.
  • … die H2OpenMap, die Wasserquellen auf einer Karte visualisiert?

Weitere Themen mit Geo-Bezug


Wo Was Wann Land
Augsburg Augsburger Stammtisch 19.05.2016 germany
Rapperswil 7. Micro Mapping Party 20.05.2016 switzerland
Zittau OSM-Stammtisch Zittau 20.05.2016 germany
Bremen Bremer Mappertreffen 23.05.2016 germany
Graz Stammtisch 23.05.2016 austria
Urspring Stammtisch Ulmer Alb 24.05.2016 germany
Düsseldorf Stammtisch 25.05.2016 germany
Essen Stammtisch 29.05.2016 germany
Stuttgart Stammtisch 01.06.2016 germany
Lübeck Lübecker Mappertreffen 02.06.2016 germany
Dresden Stammtisch 02.06.2016 germany
Rostock OSM Stammtisch Rostock 07.06.2016 germany
Salzburg FOSSGIS 2016 04.07.2016-06.07.2016 austria
Salzburg AGIT 2016 06.07.2016-08.07.2016 austria
Bonn FOSS4G 2016 Code Sprint 20.08.2016-22.08.2016 germany
Bonn Workshops at FOSS4G 2016 22.08.2016-23.08.2016 germany
Bonn FOSS4G 2016 24.08.2016-26.08.2016 germany
Bonn FOSS4G 2016 Code Sprint Part II 27.08.2016-28.08.2016 germany
Brüssel State of the Map 2016 23.09.2016-26.09.2016 belgium
Berlin Hack Weekend 15.10.2016-16.10.2016 germany
Karlsruhe Hack Weekend 29.10.2016-30.10.2016 germany

Wer seinen Termin hier in der Liste sehen möchte, trage ihn in den Kalender ein. Nur Termine, die dort stehen, werden in die Wochennotiz übernommen. Bitte prüfe die Veranstaltung in unserem öffentlichen Kalendertool und korrigiere bitte die Einträge im Kalender, wenn notwendig.

Diese Wochennotiz wurde erstellt von hakuch, Laura Barroso, Peda, rogehm, Manfred Reiter, malenki, Marc, wambacher.

¹ Fälschlicherweise stand hier ursprünglich der 21. März. Danke an Dakon für den Hinweis.

Flattr this!

by Wochennotizteam at May 19, 2016 09:51 AM

" User's Diaries"

Import of INEGI Mexico municipalities finished.

Finally, the project for importing the municipalities limits is finished. It took longer than expected considering some of the issues that arose during the project. First I would like to thank all the members of the team, and also to the volunteers who helped the team when doubts and issues arose.

Importing official data to OSM seems like a simple task at first, and it is up to certain extent,but when the amount of data is not that big, however when we talk about all the municipal limits of the whole country like in this case, problems might arise.

First problem, data availability. Before we started with this project (previous to 2014), the geographic data from the Mexican Government weren't open. there was the possibility to get them for academic or personal use but using them in a project like OpenStreetMap required overcoming a series of legal gray areas which no team would be willing to deal unless they had the resources to tackle it. The best example of this case is Google, the team from Google Maps has used Mexico's official geographic data (that means the databases from the INEGI) throughout the years, nevertheless before this data was declared open data by the Mexican Government, you needed a series of legal and licensing agreements that required analysis by a legal team, hence it was a considerable amount of expenses just to create a project of cooperation with the government, that's the kind of deal only a big corporation like google could afford to fund so, as good as the information from INEGI might be , no individual or team from the OSM community would have the means to afford the expenses required in a licensing deal just to import data to OpenStreetMap, in fact that was one of the reasons we initially thought about creating a NGO to push the geographic open data agenda within the MExican Government.

However, and in a kind of surprising way, the government took the decision to release a lot of their data as open data, including the geographical data. The way in which this happened and the factors that allowed this to happen would need another post, but if you're interested a bit of the history woul could watch the conference given by [] from the INEGI when he was invited to give a conference in the State of the Map LatAM in 2014 in Chile.

Once the data was declared open data by the government, it ceased to exist the need of an entity whose agenda was to push for the opening of the government's geographic data. It was then that we better focused on the following objective which was taking advantage of the richness of the INEGI data in OSM and it's up to certain point a perfect example of why the governments should release their data as open data, if not for the fact that the government's initiative to open their data came to fruition, our efforts would have been spent on lobbying and political activism instead of starting to work with the data and use them for the benefit of the citizens (which at the end is one of the objectives of the work the INEGI does), besides the fact that there was no certainty that all that lobbying work would really push our agenda until its final objective of opening the data, so it's a really fortunate fact that this had happened in an organic way within that institution itself and within the mexican government. Governments and institutions who manage geographic data in other countries could take note of this.

Second issue, data conversion and conservation. Uploading data within an import is not that simple, you must follow a series of procedures in order to preserve the previous information, even regardless of previous data validity, in order to avoid destroying valuable data previously contributed by osm users, it’s really complicated to validate automatically which information is valid and which isn't’ for a whole country unless there’s a very clear and specific reason such as data going against the OSM tagging rules which is the only guide to determine what data should be kept, however that’s not enough and you should make a backup previous to the import.

For starters, the data for boundaries doesn’t come ready to be uploaded to OSM out of the shapefile, it’s on a INEGI specific projection, and it’s not topologically ready to be converted from shapefile format to osm format, it needs to be reprojected, transformed, and properly split at the common boundaries, this is an important step to avoid way duplicity and we found out it will be a real challenge for more granular boundaries like the colonias boundaries.

Just an example, once converted to OSM compatible format, the limits file had more than 1,700,000 elements, which can't just be uploaded in a single changeset, it was necessary to split this huge file into several changesets in order for the OSM API to allow the data to be updated and also to validate errors in a state by state basis, which meant an enormous amount of time spent doing manual work, such as the verification of the admin_centre and the separation of non boundary data merged to boundary ways, since by replacing this limits with the addition of the backed up data we could be incurring in uploading errors from the restored data which would end up being a disservice for the osm map. The detection of such errors was done with the help of some scripts, but the evaluation of whether it was an error or not ended up most of the time being judged by the team, based on the editing guidelines of OSM, which took a considerable amount of time compared to a 100% script based validation and was of course exposed to human error.

In the case of Mexico’s municipal limits, we’re talking about 2,457 limits for which there were some previously limits present in selected states, where it was clear that they were imported from the INEGI but never documented and hence were invalid, in this case we replaced the limit with the updated INEGI data including the data identifier from the source at INEGI in order to facilitate future updates of these limits whenever the source updates them and also the other way around, for the INEGI to retrieve this data from OSM to identify where it should update its mapping efforts on the field based on what the OSM community is updating.

Third problem, idiosyncrasies, since before we started with the import, we knew from reading of the experiences of other previous imports, that some people is never happy with the imports, either because they don't share they same objectives of the importing team or because they have their own interpretation of the philosophy of openstreetmap on which they consider themselves owners and guardians for the data they contributed, and assume that no one else should touch or modify their contributed data. This notion that whomever trying to improve OSM through a big scale import is destroying or damaging OMS is well known within the community since the times of the TIGER import in the United States, but the reality is that OSM wouldn't be what it is today in part thanks to the importing efforts or it may be, only that it would take longer to improve without such efforts. Errors might be made, but if that's the cost for improving the map at a reasonable speed then I think that's a reasonable tradeoff as long as the errors are fixed.

Opinionated and polarizing views will always take place in open source communities, some folks will be satanized just because being part of a corporation or for having their own agenda, but in reality everyone has their own agenda, the point is whether those agendas contribute to the improvement of the project.

In order to keep this import current and to help out the INEGI to update the cartography of municipal limits, we set out to list every municipal boundary in Mexico’s OSM Wiki (Thanks Irk_Ley !) , this way the INEGI, and actually anyone, will be able to track which boundaries are being modified according to the local legislation which is possible for those users that have a legal backup to modify the boundaries from the ones that INEGI set.

Finally I would like to thank all from the import team noting it wasn’t only people from Telenav but we also received a great deal of technical support from the the HOT OSM team , local OSM mappers from Mexico and Puerto Rico and Europe. I don’t mention names because they’re all already listed in the import wiki ;)

by Andresuco at May 19, 2016 05:11 AM

Importación de municipios del INEGI finalizada.

Finalmente el proyecto de la importación de los límites municipales de México ha terminado. Tomó más de lo esperado en especial considerando algunos de los problemas que surgieron a lo largo del proyecto. En primera me gustaría agradecer a los miembros del equipo, y también a los voluntarios que nos ayudaron cuando surgieron dudas y problemas.

Importar datos oficiales a OSM parece una tarea sencilla y hasta cierto punto lo es cuando la cantidad de datos es pequeña, sin embargo cuando se habla de los límites municipales de un país como en este caso específico, los problemas surgen.

Primer problema, disponibilidad de los datos. Antes de comenzar con este proyecto (previo a 2014) los datos geográficos del gobierno mexicano no eran abiertos, existía la posibilidad de obtenerlos para proyectos académicos o personales pero el hecho de usarlos en un proyecto como OSM involucraba superar una serie de lagunas legales con las que ningún equipo estaría dispuesto a lidiar, a menos que tuviera los recursos para hacerlo. El mejor ejemplo de este caso es Google, el equipo de Google Maps ha usado durante años la información geográfica oficial del gobierno mexicano (Es decir las bases de datos del INEGI), sin embargo, antes de que esta información fuera declarada como datos abiertos por el gobierno mexicano, se necesitaba una serie de convenios legales de licenciamiento que requerían la revisión de abogados y por lo tanto de un gasto considerable en crear un proyecto de cooperación con dicha entidad. Ese es el tipo de convenios que sólo una corporación tan grande como Google puede darse el lujo de financiar así que por muy buena que fuera la información proveniente del INEGI, ningún individuo u organización de la comunidad OSM tendría los medios para afrontar los gastos en la gestión de un proyecto de licenciamiento tan sólo para importar datos a OpenStreetMap, de hecho esa fue una de las razones por las que inicialmente queríamos crear una Organización no Gubernamental para empujar la agenda de datos geográficos abiertos en el gobierno mexicano.

Sin embargo y de manera un poco inesperada, el gobierno tomó la decisión de abrir muchos datos, incluidos los geográficos, la manera en que ha sucedido esto y los factores que lo permitieron es materia para otro post pero si les interesa un poco de la historia, pueden ver la conferencia que dió [Nombre] del INEGI cuando fue invitado a participar en la conferencia State of the Map LatAM 2014 en Chile.

Una vez que los datos fueron declarados datos abiertos por el gobierno, dejó de existir la necesidad de crear un grupo de presión que empujara dicha agenda. Fue entonces cuando nos enfocamos en el siguiente objetivo que era aprovechar la riqueza de los datos del INEGI en OSM, y es hasta cierto punto un ejemplo perfecto de por qué los gobiernos deberían de liberar sus datos como datos abiertos, de no ser por la iniciativa del gobierno mexicano y del INEGI de liberar estos datos, nuestros esfuerzos se habrían centrado en activismo político y lobbying en lugar de poner las manos a la obra y usar los datos para el provecho de los ciudadanos (que a final de cuentas es uno de los objetivos del trabajo que hace el INEGI), además de que no existía la certeza de que todo ese trabajo realmente empujaría nuestra agenda hasta su objetivo final de abrir los datos, así que es un hecho muy afortunado que esto haya sucedido de manera orgánica dentro de esa institución y dentro del gobierno mexicano. Los gobiernos e instituciones a cargo de datos geográficos en otros países podrían tomar nota de esto.

Segundo problema, conservación de los datos, Subir datos en una importación no es tan sencillo, es necesario seguir una serie de procedimientos con el fin de preservar la información previa incluso a pesar de que no haya garantía de que esa información sea válida, esto con el fin de no destruir información previa que sea valiosa, es muy complicado determinar automáticamente cuál información es válida y cuál no para todo un país a menos que haya una razón muy específica, como que vaya en contra de los lineamientos de etiquetado de OSM y es la única guía para determinar qué conservar y qué no. Sin embargo se debe realizar un respaldo de la información previamente a la labor de importación.

Para empezar, los datos de los límites no vienen listos para ser subidos a OSM recién salidos del shapefile, están en una proyección específica del INEGI, y están topológicamente preparados para convertirse de formato shapefile a formato OSM, se necesitan reproyectar, transformar y dividir entre los límites en común, este es un paso importante para evitar duplicidad de ways y nos dimos cuenta que ese será un gran reto para la importación de límites más granulares como los límites de las colonias por ejemplo.

Tan solo un ejemplo, una vez convertidos al formato de datos de OSM el archivo de los límites contenía más de 1,700,000 elementos, lo cual no pueden ser subidos en un solo changeset, se requirió dividir este total en varios changesets a fin de que la API de OSM permitiera que se subieran tantos datos y también para validar errores estado por estado lo cual significó una enorme cantidad de trabajo manual como la verificación de los admin_centre y de la separación de datos fusionados con los límites previos ya que al sustituirlos podríamos volver a incluir una gran cantidad de errores en la información restaurada. La detección de dichos errores fue realizada con ayuda de scripts pero la evaluación de si es un error o no quedaba muchas veces a juicio del equipo basado en los lineamientos de edición de OSM lo cual tomaba evidentemente más tiempo que un script y estaba sujeta a errores humanos.

En el caso de los límites municipales de México estamos hablando de 2457 municipios para los cuales a pesar de existir previamente para algunos estados, donde era evidente que la información se importó del INEGI pero nunca estuvieron documentadas y por lo tanto eran inválidos, en este caso solo se reemplazó el límite con los datos del INEGI incluyendo la clave del dato proveniente del INEGI a fin de dar seguimiento a futuro en los casos en que el INEGI actualice un límite y también para que el INEGI sepa qué límites está actualizando la comunidad.

Tercer problema, idiosincrasia, desde antes de comenzar con la importación sabíamos por la experiencia al leer sobre importaciones previas que la gente nunca está contenta con las importaciones, a veces por que no comparten los mismos objetivos que el equipo de importación o porque tienen su propia interpretación de la filosofía de openstreetmap en la que se consideran dueños de los datos que contribuyen y asumen que nadie más debe tocarlos o modificarlos. Esta noción de que quien sea que trate de mejorar OSM a través de una importación a gran escala está destruyendo o haciendo daño a OSM ya es bien conocida en la comunidad desde los tiempos de la importación de los datos de TIGER en Estados Unidos, pero la realidad es que OSM no sería lo que es hoy sin muchos esfuerzos de importaciones, o tal vez tomaría demasiado tiempo en mejorar si no existieran dichos esfuerzos. Se podrían cometer errores pero si ese es el costo que hay que pagar por mejorar el mapa a una velocidad razonable creo que es un intercambio razonable siempre y cuando se corrijan los errores.

Opiniones polarizantes siempre habrá en las comunidades de código abierto, algunas personas serán satanizadas sólo por pertenecer a una corporación privada o serán culpados de tener su propia agenda, pero en realidad cada quien tiene su propia agenda, el punto es si esas agendas contribuyen a la mejora del proyecto.

Con el fin de mantener esta importación relevante y actualizada, y ayudar tanto a la comunidad de OSM como al INEGI a actualizar la cartografía de los límites municipales, nos dimos a la tarea de enlistar cada límite municipal en el wiki de OSM de México (Gracias Irk_Ley !), de esta manera el INEGI, y de hecho cualquier usuario, podrá monitorear qué límites están siendo modificados de acuerdo con una legislación local, lo cual es posible ya que algunos usuarios tienen dicho respaldo legal para modificar los límites que especificó el INEGI.

Finalmente me gustaría agradecer a todo el equipo de importación, notando que no sólo fue gente de Telenav, también recibimos un gran apoyo técnico de parte el equipo de HOT OSM así como de la comunidad de maperos de México, Puerto Rico y Europa. No menciono nombres porque ya todos están en la lista del equipo en el wiki ;)

by Andresuco at May 19, 2016 05:05 AM

Markdown記法 講座



  • マイクロソフトの Internet Explorer を使ったらアウト
  • マイクロソフトの Wordファイルで提出したらアウト
  • 基本的な文書の提出は MarkDown 記法でテキストファイルで提出する ​ ## 初級編 ### 見出しの書き方
  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。例: # 見出し ​ ### 箇条書きの書き方
  • *(アスタリスク)を半角で最初に記入して、半角スペースで区切り箇条書き文字列を書く。例: * 項目1 ​



by XenkGucci at May 19, 2016 03:31 AM




  • マイクロソフトのInternet Explorer使ったらアウト!
  • マイクロソフトのWordファイルで提出したらアウト!
  • 基本的な文書の提出はMarkdown記法でテキストファイルで提出する!



  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。



by Sakomaru at May 19, 2016 03:29 AM


2016年度 古橋ゼミ Markdown講座


  • マイクロソフトのInternet Explorer使用禁止
  • マイクロソフトのWordファイルで提出不可 *基本的にMarkdown記法でテキストファイルを提出



  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトルの文字列を書く。 例: # 見出し


  • *(アスタリスク)を半角で最初に記入して、半角スペースで区切りタイトルの文字列を書く。 例: * 項目



by mizu87 at May 19, 2016 03:29 AM

160519 Furuhashi Lab 日記

HOTOSM 龍野タスク

* 川は上流から下流に向かい左側が左岸、右側が右岸。

by wdolphin at May 19, 2016 03:28 AM




*マイクロソフトのInternetexplorerを使ったらアウト *Wordファィルで提出したらアウト *文書の提出はmarkdown記法でテキストファイルで提出



  • #を半角で最初に入力して半角スペースで区切りタイトル文字列を書く ### 箇条書きの書き方
  • *を半角で最初に入力して半角スペースで区切り箇条書き


by shiori*yama at May 19, 2016 03:28 AM

Markdown記法 講座はじめました。



  • マイクロソフトのInternet Explorerを使ったらアウト
  • マイクロソフトのWordファイルで提出したらアウト
  • 基本的な文章の提出はMarkDown記法でテキストファイルで提出する



  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。例:# 見出し


  • *(アスタリスク)を半角で最初に記入して、半角スペースで区切り箇条書き文字列を書く。例:* 項目1



by mariko_nagano at May 19, 2016 03:15 AM

Markdown記法講座 メモ

2016年度古橋ゼミ Markdown講座


  • マイクロソフトのInternet Explorerを使ったらアウト
  • マイクロソフトのWordファイルで提出したらアウト
  • 基本的な文書の提出はMarkdown記法でテキストファイルで提出する。



  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。 例:# 見出し

  • *(アスタリスク)を半角で最初に記入して、半角スペースで区切り箇条書き文字列を書く。 例:* 項目1



by MISA_AGU at May 19, 2016 03:15 AM

Markdown記法 講座はじめました。



  • Internet Explorer を使ったらアウト
  • マイクロソフトの Wordファイル(doc/docx)で提出したらアウト
  • 基本的な文書の提出は Markdown 記法でテキストファイルで提出する
  • 特別な理由がない限り MSゴシック/MS P ゴシックのフォント使用はアウト
  • マイクロソフトは大好きですが、特に好きなのは PowerPoint と Bing maps です。



  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。例: # 見出し


  • *(アスタリスク)を半角で最初に記入して、半角スペースで区切り箇条書き文字列を書く。例: * 項目1



by MAPconcierge at May 19, 2016 03:15 AM




  • マイクロソフトのInternet Explorerをつかったらアウト
  • MSのWordファイルで提出したらアウト
  • 基本的な文章はMarkDown 記法でテキストファイルで提出する



  • #(シャープ)を半角で最初に記入して、半角スペースで区切りタイトル文字列を書く。 ex) #見出し


  • *(アスタリスク)を半角で記入して、半角スペースで区切りタイトル文字列を書く。 ex) * 項目1



by Ricky_AGU at May 19, 2016 03:15 AM

Creating accurate maps

I'm very new to the OSM community. I signed up a few days ago and have focused primarily on where I grew up (Klamath County, Oregon) and where I live now (Eugene, Oregon) and it is surprising how little is accounted for throughout Lane County and Eugene given the population base.

I have the privilege of working at the University of Oregon and in close proximity to the department of Geography. I asked a couple colleagues there about their opinions on OSM and some affiliated products like Mapbox. Their responses to me were--in short--not very positive.

Their response made me wonder why: Why is it that the map is so incomplete? Do people want to have a say about their areal knowledge? Do they even know this project exists? As someone who has a natural affinity toward cartography and accuracy within the field, I never knew how easy it was to impart that knowledge to the world until a couple days ago; so I answered my own question. It seems like the large, resource-rich companies like Google, Microsoft, Apple, and others produce a product that is good enough for most. Perhaps I'm more pedantic in cartographic precision--and as much as I like how Google and Bing Maps have progressed--I'm not fully satisfied; local knowledge of place is key to add and it is essential for making maps more meaningful to all involved in creation and consumption.

Upon logging on this evening, I came across marczoutendijk's post which grieved over the same sentiment. Accuracy and prominence of places within the project are still hazily defined if at all and this project is far from being user-friendly. Soon, I hope it can improve. It must improve.

I'm excited to continue to work on this project to the best of my ability and I wish to learn from the greater community about how to improve my skills specifically and the project more generally.

by Mike Moresi at May 19, 2016 02:26 AM

May 18, 2016

" User's Diaries"

Now the Computer Has Died

I've been giving JOSM a lot of grief. I think that this is because it is written in Java, and my webmaster experience has caused me to be deeply suspicious of Javascript (don't bother writing; I'm well aware that they are different beasts).

A few days ago, whilst about to create a new terrace in City Heights, Mapperley, I selected a node in a building rectangle inside JOSM. It turned blood-red, which was perfectly normal. Then the whole screen turned the same colour, whilst the only key that the computer responded to was the electricity supply on/off button; that was perfectly abnormal.

To cut the long, horrible story down to size, it was not due to JOSM, but was rather because one of the two 2GB memory sticks that were bought a few years ago from Crucial had gone bad. When memory touched ~411MB the whole system died, and the entire screen was left painted the same as the last pixel used. (Added later: a phone call to Crucial and collect a Freepost address + RMA number to return & they will send two new replacements; that's what a “Lifetime Guarantee” means, even though they were bought in 2011.)

Using memtest86+ caused the same shutdown. Removing the 2 sticks (leaving the original 1GB memory in place) removed the problem. Bum.

Fixing the problem is the easy part (a new Lenovo H30 from PC-World - strip out the useless Windows10 & replace it with Debian Jessie 8.4 & we are away) (why on earth am I forced to pay for Windows?). Moving all my stuff from the old computer to the new is the difficult bit.

How To Install Debian on a modern AMD Desktop Computer:

Some truly geeky stuff for anyone else with similar equipment & problems, to try to help; first, my target system:-

  1. Lenovo H30 / Windows 10
    (is discontinued on Lenovo site; thus very cheap on PC-World)
  2. AMD A8-6410 APU
  3. EFI boot
  4. “F1” to access BIOS

Fortunately, I obtained a brand-new Jessie (Debian 8.4) ISO file to install. That is necessary as the H30 has the BIOS within a hdd partition + boots from a EFI partition (I believe that this was introduced at Windows 8.1). Debian will handle all that transparently on install; just as well for me as I was ignorant of it until afterwards, and may otherwise have tried to use an ancient Wheezy Live-Boot USB Stick.

a) Debian Basics

  1. It has a user/superuser system
    (the user always logs in under their user-name)
    (the ‘root’ superuser is used only for administration)
  2. “Stable” is the first of 3 possible distributions
    (currently called ‘Jessie’, it is the least buggy distro)
  3. “Testing” is the next distribution
    (currently called ‘Stretch’, it will eventually become the “Stable” distro)
  4. “Unstable” is the final option
    (always called ‘Sid’, it will eventually become the “Testing” distro)

The Debian links below often show ‘8.4.0’ in the URL. That is the current version of Jessie. As Jessie gets updated, those links will break (the version will become ‘8.5.0’, etc.).

b) Create an Install Stick

You need:

  1. 2GB USB Stick
    (all contents will be wiped)
  2. Debian ISO file
    (Install Help)
  3. An Internet Connection via Ethernet
    (anything other than Ethernet may need drivers installing, which may not come on the stick)

I downloaded debian-8.4.0-amd64-CD-1.iso (630 MB). With hindsight, because I was going to use the lightweight-XFCE4, I could have downloaded debian-8.4.0-amd64-xfce-CD-1.iso (646 MB). It did not actually matter, as I was asked what Desktop Manager I wanted to use during install, and chose ‘xfce’ at that point. The issue in all cases is that you only need CD1 (unless you do not have an internet connection for the machine).

The ISO needs to be printed upon the USB stick (or CD if you decide to go all old-school). Here is how to do it from a Linux terminal:

  1. Check that the downloaded ISO has the correct md5
    (also download MD5SUMS file)
  2. Put USB stick in computer & check it's device name
  3. Use dd to transfer to the USB stick

So, the first thing is to check the md5 for the downloaded file (this guarantes that the entire file has downloaded intact):

alex@home:~$ cat Downloads/MD5SUMS | fgrep debian-8.4.0-amd64-CD-1.iso   
c58a9df992d6e119121babbac9bb5a13  debian-8.4.0-amd64-CD-1.iso   
alex@home:~$ md5sum Downloads/debian-8.4.0-amd64-CD-1.iso   
c58a9df992d6e119121babbac9bb5a13  Downloads/debian-8.4.0-amd64-CD-1.iso   

md5 is correct, so now check the newly-inserted usb-stick:

alex@home:~$ lsblk   
sda      8:0    0 931.5G  0 disk   
├─sda1   8:1    0   512M  0 part /boot/efi   
├─sda2   8:2    0 923.6G  0 part /   
└─sda3   8:3    0   7.4G  0 part [SWAP]   
sdc      8:32   1   1.9G  0 disk   
└─sdc1   8:33   1   1.9G  0 part   
sr0     11:0    1  1024M  0 rom

The stick is auto-mounted in /media if formatted. dd needs to be used on an unmounted device:

alex@home:~$ sudo umount /dev/sdc1
[sudo] password for alex: 
umount: /dev/sdc1: not mounted

(the stick is not formatted)

alex@home:~$ sudo dd if=Downloads/debian-8.4.0-amd64-CD-1.iso of=/dev/sdc bs=1M
630+0 records in
630+0 records out
660602880 bytes (661 MB) copied, 408.09 s, 1.6 MB/s

That is a terrifying command to get wrong! As you are working as root ('sudo') it will allow you to shaft any part of the computer that you want. Note that 'if'=='in-file', 'of'=='out-file', 'bs'=='chunks of bytes to transfer at a time'. When the usb-stick stops flashing & the final 3 lines above are printed, the stick is ready to use.

Now to get the computer ready:

c) Install Debian into the H30

Warning! This deletes absolutely everything from the Hard Disk
(Possibly the Recovery partition is left, but I haven't tried to check)
(The BIOS untouched)

You may receive the following message on startup with the USB stick in the slot:

Secure Boot Violation
Invalid signature detected
Check secure boot policy in Setup

The H30 was shipped set to “Quiet Mode”, so no messages came up ordinarily at bootup. Even the telephone Customer Support was unsure of the command to get into Setup (it is 'F1') (no quotes) (you will need to be very quick as it is a very short bootup). You will find the Secure Boot Policy in there, which stops anything else other than the existing OS from booting. Set it to “Disabled”.

From that point, just follow the prompts to install Debian (very, very simple).

d) Final Setup

To perform any admin, at the moment, means switching to the root user. If you use the terminal a lot you will want to use 'sudo' (“superuser do”) instead. Here is how: (in a terminal):

alex@home:~$ su
root@home:/home/alex# adduser alex sudo

“su” is the “switch user” command (default: switch to root), which then needs the root password. The final line puts the user into the “sudo” group. From that point on, entering ‘sudo’ in front of a command (will require one's own password the first time) will perform the command as the root user.

The H30 has hardware that does not have Open Source drivers. It does have drivers for Linux (Debian), but those drivers come as pre-compiled binaries from the manufacturer, and the source-code is not available. For that reason, Debian refers to the sources as “non-free” (even though there is zero financial charge) (all that sort of stuff gets up my nose as well, but I put up with it since my Synaptic currently has 42,981 packages freely available, many of which are best of their class).

The main problem was that – for whatever reason – that Debian sets up the Update (“Repository”) system only with a ‘main’ repository which, as explained in the previous paragraph, means that the system will not have certain vital systems working. In my case that was Bluetooth, which is absolutely classic. It is easily fixed.

The easiest way to fix this is via Synaptic (graphical update utility) (use Menu: Settings|Repositories|Section(s)). However, being GUI means that I cannot show you here. So, using a terminal:-

alex@home:~$ sudo cat /etc/apt/sources.list
deb jessie non-free contrib main   
deb-src jessie non-free contrib main  

deb jessie/updates main non-free   
deb-src jessie/updates main non-free 

# jessie-updates, previously known as 'volatile'   
deb jessie-updates main non-free   
deb-src jessie-updates main non-free 

At the end of the lines that begin with “deb” or “deb-src” are the words “non-free contrib main”. As supplied, those lines contain only “main”, which means that the updates will only investigate that Repository. Add the other 2 words.

That change now means that Synaptic can find the manufacturer binaries. The easiest way is to find the error (or ‘fail’) message in the ‘dmesg’ dump, then to search within Synaptic with a snippet of that report. Here is a live example:

(‘dmesg’ only shows the current hardware report, so I'm using ‘kern.log’ to access historic logs)

May 17 13:36:57 ng3 kernel: [    5.823268] ieee80211 phy0: Atheros AR9565 Rev:1 mem=0xffffc90011500000, irq=32
May 17 13:36:57 ng3 kernel: [    5.847992] usbcore: registered new interface driver btusb
May 17 13:36:57 ng3 kernel: [    5.969014] usb 1-1.4: firmware: failed to load ar3k/AthrBT_0x31010000.dfu (-2)
May 17 13:36:57 ng3 kernel: [    5.969149] usb 1-1.4: Direct firmware load failed with error -2
May 17 13:36:57 ng3 kernel: [    5.969155] usb 1-1.4: Falling back to user helper
May 17 13:36:57 ng3 kernel: [    5.971359] alg: No test for crc32 (crc32-pclmul)
May 17 13:36:57 ng3 kernel: [    5.989585] Bluetooth: Loading patch file failed
May 17 13:36:57 ng3 kernel: [    5.989657] ath3k: probe of 1-1.4:1.0 failed with error -12
May 17 13:36:57 ng3 kernel: [    5.989716] usbcore: registered new interface driver ath3k

Synaptic first needs the “Reload” button pressing as to update from all the Repositories & find recent changes. Next, searching on “AthrBT_0x31010000.dfu” will land on the “firmware-atheros” package + show that the H30 has the ath3k Bluetooth chipset. Marking that package for install, then applying that command (and rebooting) removes the error + makes the adapter active.

A similar process was needed for (I believe) the Gigabit portion of the Ethernet adaptor:

May 17 13:36:58 ng3 kernel: [   13.861538] r8169 0000:02:00.0: firmware: failed to load rtl_nic/rtl8105e-1.fw (-2)
May 17 13:36:58 ng3 kernel: [   13.861679] r8169 0000:02:00.0: Direct firmware load failed with error -2
May 17 13:36:58 ng3 kernel: [   13.861685] r8169 0000:02:00.0: Falling back to user helper
May 17 13:36:58 ng3 kernel: [   13.863552] r8169 0000:02:00.0 eth0: unable to load firmware patch rtl_nic/rtl8105e-1.fw (-12)
May 17 13:36:58 ng3 kernel: [   13.991208] r8169 0000:02:00.0 eth0: link down
May 17 13:36:58 ng3 kernel: [   13.991233] r8169 0000:02:00.0 eth0: link down
May 17 13:36:58 ng3 kernel: [   13.991311] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
May 17 13:36:58 ng3 kernel: [   14.008189] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
May 17 13:37:00 ng3 kernel: [   15.647680] r8169 0000:02:00.0 eth0: link up
May 17 13:37:00 ng3 kernel: [   15.647695] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

The search string “rtl8105e-1.fw” found “firmware-realtek”. Marking & installing that fixed the last of the hardware issues.

by alexkemp at May 18, 2016 10:10 PM

Fermate SAF Udine/11

Ultime fermate aggiunte. Ora seguirà una revisione per controllare la presenza di tutte le fermate urbane ed extraurbane ad Udine e dintorni.

Ad un primo controllo risultano ancora mancanti queste fermate (quelle non ancora mappate sono solamente extraurbane):

032:Vittoria/1°Maggio: a causa della realizzazione del parcheggio, la viabilità è stata modificata. La fermata in direz.N è già mappata, ma senza nome 041:Oberdan 2a: fermata extraurbana, divisa in 3 zone di carico 044:De Rubeis: la fermata in direz.S non ha la tabella 129:25 Aprile/Campo Rugby: la fermata in direz.O non ha la tabella 136:Argentina/Venezuela: la fermata, in teoria esistente, non ha nè palina, nè tabella. Da rivedere 165:V.leTricesimo/Paderno: la fermata in direz.S non ha la tabella 185:Bariglaria 1a: la fermata in direz.N, in teoria, è soppressa, ma la palina è ancora presente 212:Bariglaria/Beorchia: la fermata esistente (da orario) è in direz.N, ma risulta presente (sul posto), invece, la fermata in direz.S 228:Di Brazzà/Area Peter Pan: la fermata in direz.O non ha la tabella 237:Melegnano/Scuola Negri: non presente la fermata in direz.O 303:Zugliano:Via Lignano: non ancora mappata 329:Marinelli: non ancora mappata la fermata extraurbana 355:Cotonificio/Sondrio: la fermata in direz.S non ha la tabella 369-371:Marinoni: con l'apertura del terminal studenti, da rivedere il futuro assetto delle fermate. 388:PdP:Colombo/Rovaredo: non ancora mappata 472:Colugna:V.S.Daniele: non ancora mappata 491-492-492:F.Umberto: fermate extraurbane non ancora mappate

by Gabriele Dri at May 18, 2016 08:37 PM

Improving the OSM map - why don't we? (13)

Improving the OSM map - why don't we? (13)

Why so many people are not using OSM.

Do you recognize the renderer that was used for the above screenshot? I'm pretty sure you can't. Because it wasn't rendered but printed in the Times Comprehensive Atlas of the World.
Looking at this map, it is clear (at least to people who are familiar with "paper" maps [1]) what we see:
* A number of Islands that have a name as a group (Canary Islands) that are part of mainland Spain
* Each Island has its own name (printed in italics or bold italics)
* Each Island has a capital (printed in bold, but this is not true for all the Canary Islands)
* A number of towns is printed in normal type

Now let's see how OSM based maps and renderers show this to the world. The same Islands, with three different ways of rendering (Humanitarian, Mapquest and Mapnik).
The most striking omission (to me) is, that none of the islands is shown with their name and Mapnik shows every Island as "España".
Even when zooming in, the names of the Islands never (and I mean NEVER) show up (I'm supposed to see Tenerife now somewhere on the map):

Now, what kind of a map is that?? Not showing what is most important!?!
Is there a road (top picture) running from Santa Cruz de Tenerife to España?
When I use a (printed) map or atlas, I can see at the large scale maps (1:500.000) what I need to find my way. At that scale I'm not interested if there is a paved/unpaved way ahead of me. And even less I do care about the traffic signs that I might see once I'm there.

I know that everything I'm looking for (and much, much more) is in the OSM database, but why is it shown to me at the wrong moments (if at all) and at the wrong zoom levels?
BTW, Google maps is not doing much better than OSM, showing (some) Island names at high zoom levels.
Do I use OSM myself? Yes!! All the time, and because I have learned to ignore all the crap it is giving me (like showing me the map in Chinese when viewing China, even if English is the language I have installed as my basic language), and because I know the strength it has with the right tools, to me it is the perfect map.
But to a lot of people who are used to a regular printed map or to Google, OSM is just a funny experiment that you can't even use decently on a mobile phone.
Of course, there are tools and apps that use the OSM data in a much more user-friendly way (especially on mobile devices), but why can't be a bit more user friendly?

One more example of the incompleteness of OSM.
In the part of the map I'm showing you here, we are supposed to see the capitals of the UK (London), France (Paris), Belgium (Brussels), Luxemburg (Luxemburg) and Holland (Amsterdam). Can you spot them?

Even worse, at this zoomlevel the only capitals shown on the map are London, Dublin and Budapest!!
Madrid, Paris, Brussels, Amsterdam, Luxemburg, Rome, Vienna, Berlin, Oslo, Kopenhagen, Stockholm? What?? Where?? Are they gone??

Friends I'm trying to move over to use OSM (by pointing them to my own openpoimap, I often tell, they call it a "slippy-map", but you better consider it a "shitty-map".

I hope that the developers who are working on the way the basic map is being presented to the users, read this and try to create a map that users recognize instead of being puzzled.
I have said it before, at this moment OSM is a map for mappers, not for users.

[1] Of course there are people who have never seen or used a printed map before, and for those OSM is maybe a great tool, but I doubt it.

by marczoutendijk at May 18, 2016 08:16 PM

Bone Killian


Bees are happening.  Run for your lives.


by Adam at May 18, 2016 07:44 PM

" User's Diaries"

Datos y estdisticas

Alquien sabe como puedo obtener datos estadisticos de acceso a los mapas en una determinada region?


by Henry Vallejo at May 18, 2016 06:33 PM

Carei ... done !

I did it !!!! I finished tracing Carei town ! Please check out my upload !!

by kokeinyesdi at May 18, 2016 05:40 PM