OpenStreetMap

Users' diaries

Recent diary entries

Hacking on mobile apps with the London crowd

Posted by zool on 16 August 2015 in English (English)

I made a last-minute dash down to the London OSM Hack Weekend and had a lovely time there.

I worked on a mobile app which I was pleased to get into a basically working state. It is called osmbi3, which stands for OpenStreetMap Building Information and/or Zombies. The aim was to geolocate the user and find nearby buildings using an Overpass query. This could then be linked to building management information or form the basis for some location-based game. Having managed the basic task, showing a map with annotated every building with an icon reading "yes!", I set out to try and get OAuth working against the OpenStreetmap server from a mobile device, a task which I have yet to achieve.

So, what last weekend was a very simple but perfectly functional app, is now buggy as hell while it tries to do more. However the source code is on github and i will probably keep working on it, because I could use a very lightweight building editor which doesn't require any typing.

I am doing a dangerous amount of app development now, helping finish up a project from the last codethecity event in Edinburgh, and working on a dinosaur card game app for - eventually with? - my boy. But it's all apache cordova and webviews, so i'm not doing anything too evil.

Apart from a successful weekend's hack, I was very glad to visit London put faces and voices to some names I only know from the internet; also to reconnect with some folks I hadn't seen for the last ten years. If only more people in the wider community would make the journey up to State of the Map Scotland!

SRTM global 1 arc second release complete

Posted by yvecai on 16 August 2015 in English (English)

For those interested in DEM data, the release of void-filled, 1 arc-second and global SRTM data is now completed at USGS. See https://lpdaac.usgs.gov/nasa_shuttle_radar_topography_mission_srtm_global_1_arc_second_data_released_over_middle_east

To Do

Posted by Prototyp206 on 15 August 2015 in German (Deutsch)

Auen - Schiefling Schieflinger Straße 58 Straßenname und Nr. unbekannt

Velden - Rosegg Kernjakstraße Neue Häuser, nr. unbekannt

Schloss Velden Nr?

Klagenfurter Straße 26 .....

OpenStreetMap Carto v2.33.0

Posted by pnorman on 15 August 2015 in English (English)

OpenStreetMap Carto 2.33.0 has been released. This release focuses on cartographic style improvements, but the release notes also include 2.32.0.

The biggest changes are

  • A randomized symbology for forests for natural=wood and landuse=forest #1728 #1242

A long time in the works, this improvement has finally landed. The two tags were merged - they are indistinguishable to the data consumer. A randomized symbology was first suggested by SK53 at SOTM-EU 2014, and this feature would not have happened without his extensive research, or imagico tools for creating an irregular but uniformly distributed and periodic dot pattern

As all residential, unclassified, and service roads in a city became mapped the rendered view became over-crowded, bloblike, and difficult to read.

  • Unification of footway/path and rendering surface of them

The mess that is highway=path is well-known, and it is necessary to do some kind of processing as a data consumer. A distinction is now made between paved and unpaved footways.

  • Rendering of Antartic ice sheets from shapefiles #1540

Ice sheets in Antartica are a bit of a special case, and pre-generated shapefiles are now used

  • Mapnik 3 preperations #1579

The style is not yet fully tested with Mapnik 3 and we don't claim to support it, but several bugs were fixed. Most of the work was done on the Mapnik side

  • No longer rendering proposed roads #1663 #1654

  • Power area colour adjusted #1680

  • Better place label order #1689

  • meadow/grassland and orchard/vineyard color unification #1655

  • Render educational area borders later #1662

  • New POI icons

A full list of changes can be found on Github

Mapping Hervery Bay, QLD

Posted by TuanIfan on 15 August 2015 in English (English)

I started mapping the city of Hervey Bay, QLD a few days ago. It's a nice city with close proximity to the coast and serves as the gateway to Fraser Island. Incorporated from 4-5 nearby coastal villages, Hervey Bay surely has much potential for tourism.

However, it does not have a hard urban core, a shopping precinct with old buildings and parklands and blabla.. Instead, it possesses a long coast, which is ... too long and serves no link to any combined urban centre as in other real city. Ah, the area of Pialba around the Hervey Bay library, Pialba Place and USQ can be said as a preparatory centre, however, it is too small and underdeveloped, thus cannot be considered as a real centre.

Perhaps, I believe, the Council needs to work more on this to make it a liveable place.

** In OSM, I have to redraw the roads, which seem to have been automatically generated from incorrect data. I also have classified some roads as Tertiary and redraw several roundabouts.

The USQ campus was drawn as well, although I'm not sure if the campus area is correct or not.

Hervey Bay, QLD

Pialba centre

Cooperation between free content projects: how to link from Wikipedia to OSM

Posted by Polyglot on 14 August 2015 in English (English)

This blog entry describes how and why the following module was developed:

https://en.wikipedia.org/wiki/Module:OSM

In the mean time I added extensive documentation to it, which might be more interesting than what I wrote here... so go and have a look!

https://en.wikipedia.org/wiki/Module:OSM/doc

With the advent of Wikidata my interest in Wikipedia flared uponce more. I'm a mapper for Openstreetmap in the first place, but last year I already made a little sidestep to Wikivoyage. That's a project which is closer in many ways to Openstreetmap than Wikipedia.

Recently I started adding wikidata tags to streets and other objects in Openstreetmap. Which in itself doesn't do all that much. So a way is needed to make this available to the rest of the world. Wikipedia seems like the way to accomplish this.

I had already experimented a bit with links to saved queries on Overpass Turbo. But creating these queries from scratch over and over again and creating such links to them, isn't the most straightforward way to get things done.

When it became clear to me that sometimes an additional query of wikidata may be necessary, before invoking Overpass, I knew I had to tackle the problem in another way.

This made me look into Lua, the scripting language which was chosen to automate the plethora of MediaWiki projects. After one day I came up with a working script (in the mean time it's been developed quite a bit further):

On the Dutch Wikipedia reception was luke warm. I'm afraid, I hadn't been able to carry across what I was trying to achieve. On the English Wikipedia a Lua developer saw the potential and he helped me to improve the code and explained me how to go about adding test cases. This helps a lot to not introduce bugs while attempting to add new features. For the case of querying several Q-numbers at once using a regex query, help came from a specialist in Overpass.

So this saved query:

[http://overpass-turbo.eu/s/aFt]

now looks like this in the article:

{{#invoke:OSM|etym|display=Streets named after Leuven|timeout=50|query=[highway]|coord=50.879;4.701;9}}

which results in the following query:

[timeout:50][out:json]; ( node["name:etymology:wikidata"="Q118958"]highway; // remove the ({{bbox}}) if you want the query to be executed globally way["name:etymology:wikidata"="Q118958"]highway; relation["name:etymology:wikidata"="Q118958"]highway; ); out geom;

The difference with the stored query is that only streets closer to Leuven are fetched. If the user wishes to do so they can either remove the ({{bbox}}) statements or they can move the map to another region and press Run. In case the user also wants to see other objects named after Leuven, they can remove the [highway] part.

Now, let's hope the Wikipedia contributors at large see value in this. I deployed it on the French Wikipedia as well and will probably continue with Spanish, German and Esperanto. Feel free to deploy it on other language versions as well. I will keep all the modules in sync. I'm only going to develop test cases on the English Wikipedia, so that will be the primary place to continue development. One test is failing because of lack of arbitrary access, but that should be resolved shortly.

Actually there is a whole plethora of possibilities:

  • objects named after the subject of the Wikipedia article (on condition they got name:etymology:wikidata tags on the OSM side)
  • the object of the article itself (on condition they got wikidata tags on the OSM side)
  • other objects related to the article (this is probably not OK with Wikipedia policies)
  • objects of which the subject of the article is the architect or the artist who created them (architect and artist.wikidata)
  • objects related directly to the subject (subject.wikidata), this can be tombstones as well
  • objects carrying brand:wikidata or operator:wikidata tags
  • relations representing public transport lines. The names of the stops are emphasized with help of MapCSS styles
Location: Hertogensite, Leuven, Flemish Brabant, Flanders, 3000, Belgium

New road style for the Default map style, the full version - PR, casings on z11

Posted by Mateusz Konieczny on 14 August 2015 in English (English)

PR

Next pull request for changing road style was opened. This time it is a final stage of proposing a rendering change including new colours for roads, new widths and rework of a railway styling. Feedback is welcomed.

PR link: https://github.com/gravitystorm/openstreetmap-carto/pull/1736

All changes before PR were squashed into two commits - as result changes done based on feedback since creating PR are listed on https://github.com/gravitystorm/openstreetmap-carto/pull/1736/commits

Casings on z11

One of repeated comments was that casings on z11 are not working well. Therefore I prepared also another casingless variant for z11. Below are test renderings for some places (current rendering, rendering from PR, potential rendering using low zoom styling for z11)

Auckland

Brussels

Iceland, Reykjavik

India

Japan

Malmo

New Jersey

Rural UK

Russia

z11 will be now using casingless style, especially as attempt to improve casings on low zoom by reducing it failed to solve problems with pixelated casings and managed to create new.

Improving the OSM map - why don't we? [10]

Posted by marczoutendijk on 13 August 2015 in English (English)

Fix the fixme/FIXME/FixMe/Fixme/Fixme: !!

During my research of the taginfo database, more than once I was staring flabbergasted to the proliferation of keys.
In normal use a single key with its value would give enough information to describe the object you just created. E.g. the shop=* key. The value for that key comes from the suggested values in the wiki.
But what if one shop sells things that belong in various categories from the wiki? Like this one: You cannot add 5 shop keys to one node (which is ok and according to the rules of good database design; any key should exist only once for a given object). Suppose you could, which one should the renderer show? All 5? On the same spot on the map? You must be kidding!
So what now? Should you add a new node for every shop-type, including all the address information? Or should you just tag it with shop=food and possible list all the different values in a note? For this particular case the choice of the mapper wasn't all that wrong, although I would have preferred a different solution.


On now to the fixme-chaos!

Why are so many people coming up with a new variation on the very well defined fixme key ?
Below you see an overview of the most of those variations.
The number of times used is also in the list. The first (and most used) 2 are:
fixme
FIXME
I do have a question about the second version:
WHY DO WE NEED AN UPPERCASE VERSION?????
Is the FIXME more urgent to fix than the fixme?
Do we have name and NAME, shop and SHOP, landuse and LANDUSE? (For LANDUSE the answer is yes but used only 2498 times, and Landuse is used 31 times. For NAME the answer is alo yes, 393 times).
But do we NEED those uppercase versions?
I don't care that they are being used probably because of typing errors, I do care about a system which enforces consistent and reliable data entry.

Almost always it is possible to just have one single key and explain in the value of that key what needs to be fixed.
Why:
fixme:admin_level=7,8
and not:
fixme=admin_level should be 7,8
If you argue that it is more clear in this way (at first sight) what needs to be fixed, then I start a proposal that we should start using:
shop:bakery=yes instead of shop=bakery
amenity:bench=yes instead of amenity=bench
landuse:grass=yes instead of landuse=grass
Maybe even better is shop:bakery:yes=true and then use shop:bakery:yes=false for the Butcher?
Got the picture?


One reason I could think of why there exist so many variations is this: Why did the mapper use 4 times FIXME:X (he should have used fixme:x in the first place) and not just put all the city names - that apparently are missing from the map - in one single fixme=longlistofcitynames?
The reason is that no keyvalue can be longer than 255 characters, a stupid limitation that in current database design is absolutely not necessary.
Read the comments to my diary entry and read this.

Why are so many variations a problem?

Given the fact that OSM is a mondial database, it is logical that we need a greater number of tags to describe shops worldwide than we need to describe shops just in the UK. Cultural and social differences are reflected in the database and we should allow for it and respect it.
But so many keys are being used so little that we really need to think about ways to get a more consistent database.
Searching for something is probably the most useful task we keep database for. Tools (like OpenPoiMap rely on consistent data. If you want to know all amenity=atm in a given area, do you expect you have to search for amenity:atm=yes* as well?
With OpenPoiMap you can easily search for fixme or FIXME because this tag is easily available in its list of choices. Do you have some spare time? Then try to fix what what needs to be fixed in London! But for the other 300+ variations of the fixme key, you're on your own! See my list above.

Conclusion.
Roughly 1300 keys are being used more than 10.000 times and they cover probably 99% of the data in the OSM database. That leaves us with about 53.000 keys with values that no one knows about and probably no one cares either. Do you?

Tocando música por todo mundo

Posted by Ricardo Gómez on 13 August 2015 in Spanish (Español)

Soy músico y por ese motivo viajo por todo el mundo un compañero de la banda me enseño esta web y a partir de ahora sitio donde viajemos sitio que añadiré al mapa.

Недельное задание 22: статистика

Posted by edward17 on 13 August 2015 in Russian (Русский)

На прошлой неделе мы обрисовывали по спутниковым снимкам город Белгород-Днестровский Одесской области. Проект в OSM Task Manager находится здесь.

Ниже - статистика по изменённым объектам. statistics statistics

Активность участников: statistics

Как изменился центр города (правки были, в основном, там), можно увидеть на анимации. Вдруг кому-то понадобится, гифка на весь город (осторожно, 8 МБ!).

Большое спасибо пользователю Xmypblu, с его помощью зарегистрировался в сервисе ITO OSM Mapper, который позволяет делать интересные визуализации. Они представлены ниже.

Последний редактор объектов (в полном размере): visualisation

Время последнего изменения объектов (в полном размере): visualisation

И ещё гифки, сделанные из картинок, экспортированных тоже из ITO OSM Mapper:

Участие приняли 4 пользователя, которые отправили 41 пакет правок с 14 921 правкой.

Сейчас: пожарные гидранты.

Location: совхоз им. 28 июня, Белгород-Днестровский, Белгород-Днестровский городской совет, Одесская область, 67700-67719, Украина

Inmobiliaria internacional

Posted by royalcosta on 13 August 2015 in Spanish (Español)

He creado una inmobiliaria y cada vez que venda una casa la marcaré en el mapa.

Viaduc en Haïti

Posted by Xapitoun on 13 August 2015 in French (Français)

Haiti dispose de son premier viaduc, le viaduc de Delmas.

Durant ces 2 ans de construction, toutes les modifications de circulation ont été prises en compte et ajoutées à OSM.

Il reste maintenant à bien dessiner le viaduc et ses voies de connexion.

Location: Carrefour Aéroport, 1re Saint Martin, Commune de Delmas, Arrondissement de Port-au-Prince, Département de l'Ouest, HT6123, Haïti

Water wells in South Sudan

Posted by Jotam on 13 August 2015 in English (English)

Since the year 2008 the Christian charity Water is Basic has managed to drill more than 500 water wells all over South Sudan. With their permission, I have imported the coordinates of around 450 of them into OSM. It is my hope that this little contribution can help to relief the suffering of the people of South Sudan in the ongoing civil war. The wells can be identified by the tag "operator=Water is Basic".

Location: Mahute, Yei, Central Equatoria, South Sudan

Show Tv donmadan izle

Posted by Canlı on 13 August 2015 in Turkish (Türkçe)

Show Tv donmadan izlemek artık çok kolay bisiklet yada arabayla seyahat ediyosanız show tv kesintisiz olarak seyretme imkanı sizlerin elinde olacaktır. Show tv hd izle mek isteyenlerde olacaktır ama hatları yeterli gelmeyebilir işte bu yüzden hattınızın minimum 16mps olması gerekmektedir. http://www.tvizleyim.com/show-tv burdan izleyebilirsiniz.

Cartographie des pistes et sentiers

Posted by JackAurel on 13 August 2015 in French (Français)

Souvent en vadrouille en montagne à pied ou à VTT, surtout en France, je ne manque pas de mettre à jour les pistes, sentiers ou autres éléments topo.

administrative entities, consistency?

Posted by rayKiddy on 13 August 2015 in English (English)

In my previous, I captured all the relations in California and around it with:

 result = api.query('relation'
               '["boundary"="administrative"]'
               '(32.0,-125.0,42.0,-114.0);'
               'out body;')

I had been wondering about some of the things I was seeing in the "is_in" tag. This explains some of that. There is obviously a bit of inconsistency here.

 $ grep '^is_in ' rel01.txt | sort | uniq -c
       2 is_in --> California; CA; USA
       1 is_in --> Irvine
       2 is_in --> Los Angeles County
       2 is_in --> Santa Barbara County
       1 is_in --> USA
       4 is_in --> USA, Arizona
     185 is_in --> USA, California
      68 is_in --> USA, Nevada
       1 is_in --> USA, Utah
       1 is_in --> Ventura County
 $ 

Well, maybe just using "code" tags makes it better.

 $ 
 $ grep '^is_in:country_code ' rel01.txt | sort | uniq -c
       2 is_in:country_code --> MX
     258 is_in:country_code --> US
 $ 
 $ 
 $ grep '^is_in:state ' rel01.txt | sort | uniq -c
       4 is_in:state --> Arizona
     185 is_in:state --> California
      67 is_in:state --> Nevada
       1 is_in:state --> Utah
 $ 
 $ 
 $ grep '^is_in:state_code ' rel01.txt | sort | uniq -c
       4 is_in:state_code --> AZ
     179 is_in:state_code --> CA
      67 is_in:state_code --> NV
       1 is_in:state_code --> UT
 $ 
 $ 
 $ grep '^is_in:country ' rel01.txt | sort | uniq -c
       2 is_in:country --> México
       1 is_in:country --> United States of America
     256 is_in:country --> USA
 $ 

I think that is a "yes". And just to see all the keys. I have no idea what some of these mean, but here they are:

 $ awk '{print $1}' rel01.txt | sort | uniq -c
       2 $
       1 3
       1 addr:country
       2 addr:even
       2 addr:odd
       1 addr:state
     537 admin_level
      87 alt_name
       3 alt_name:vi
       3 amenity
      79 attribution
       1 board_type
     219 border_type
     591 boundary
       1 census:population
       2 construction
      58 county:abbrev
      58 county:ansi
      58 county:name
       1 county:name:vi
      39 created_by
       1 currency
       3 ele
       1 FIXME
       2 flag
       2 gnis:Class
       2 gnis:County
       2 gnis:county_id
       2 gnis:County_num
       2 gnis:created
       3 gnis:feature_id
       2 gnis:id
       2 gnis:ST_alpha
       2 gnis:state_id
       2 gnis:ST_num
       1 history
       1 import_uuid
       1 int_name
     267 is_in
       1 is_in:continent
     259 is_in:country
     260 is_in:country_code
       1 is_in:county
     259 is_in:iso_3166_2
     257 is_in:state
     251 is_in:state_code
       2 ISO3166-1
       2 ISO3166-1:alpha2
       2 ISO3166-1:alpha3
       2 ISO3166-1:numeric
       8 ISO3166-2
       1 land_area
       3 landuse
       1 layer
       1 military
     573 name
       1 name:ab
       2 name:ace
         ....
       2 name:zh-min-nan
       2 name:zh-yue
       2 name:zu
      98 nist:fips_code
      94 nist:state_fips
       9 note
       6 odbl
      12 official_name
       1 official_name:vi
       1 old_name
       1 old_name:vi
       1 owner
     364 place
      97 place_name
      26 population
      21 ref
       6 ref:fips
       1 relations
       1 route
       2 Script
       2 short_name
       1 short_name:vi
     332 source
     236 tiger:CLASSFP
     238 tiger:CPI
     237 tiger:FUNCSTAT
     237 tiger:LSAD
     236 tiger:MTFCC
     238 tiger:NAME
     238 tiger:NAMELSAD
     238 tiger:PCICBSA
     237 tiger:PCINECTA
     238 tiger:PLACEFP
     238 tiger:PLACENS
     238 tiger:PLCIDFP
     267 tiger:reviewed
     237 tiger:STATEFP
       9 timezone
     591 type
       5 website
      16 wikidata
     464 wikipedia

Simplified access for administrative entities? (perhaps solved)

Posted by rayKiddy on 13 August 2015 in English (English)

Yikes, this stuff is just not terribly ... intuitive. I received a helpful response from maxerikson. He said:

Here's an Overpass Turbo query that returns all boundary=administrative that
are inside the current view:

 [out:json][timeout:25][bbox:{{bbox}}];
 relation["boundary"="administrative"];
 out body;
 >;
 out body;

Now, just for giggles, google a question like "specify bbox in overpass?" It is a bit too abstract. It did point me to the OP documentation but I already knew where that was. What I wanted to know was: How do I replace that {{bbox}} above with a bbox defined by coordinates.

It turns out to be:

 relation["boundary"="administrative"](37.3612,-122.082,37.4326,-121.965);out body;

It is not:

 relation["boundary"="administrative"](-122.082,37.3612,-121.96537.4326);out body;

This is wrong even if the documentation insists that the bounding box is "usually" specified in the order: min long, min lat, max long, max lat. Which clearly does not work. Er.....

Well, and then one has the question of how one is going to access the data. I wanted to use python, so I installed overpy.

I finally got this.

 $ cat 1.py
 import overpy

 api = overpy.Overpass()

 # bbox = min Longitude , min Latitude , max Longitude , max Latitude 

 # My box:

 #    "minlat": 37.3612,
 #    "minlon": -122.082,
 #    "maxlat": 37.4326,
 #    "maxlon": -121.965

 # result = api.query('[out:json][timeout:25]'
 #    '[bbox:{{bbox|-0.489|51.28|0.236|51.686}}];'
 #    'relation["boundary"="administrative"];'
 #    'out body;'
 #    '>;'
 #    'out body;')

 #result = api.query('[out:json][timeout:25]'
 #    '[bbox:{{bbox|-122.082|37.3612|-121.965|37.4326}}];'
 #    'relation["boundary"="administrative"];'
 #    'out body;'
 #    '>;'
 #    'out body;')

 # result = api.query("node(50.745,7.17,50.75,7.18);out;")

 # result = api.query('node'
 #     '["name"~"^Holtorf"](49.7,7.1,50.8,7.25);out body;');

 result = api.query('relation'
                    '["boundary"="administrative"]'
                    '(37.3612,-122.082,37.4326,-121.965);out body;')

 print 'relations %d' % len(result.relations)

 for relation in result.relations:
     print ''
     for tag in relation.tags:
         print '"%s" --> "%s"' % (tag, relation.tags.get(tag, "n/a"))
 print ''
 $ 

Wow. That was certainly ... easy. Yeah, that's the ticket. It was easy.....

highway=footway, path solved?

Posted by jremillard on 13 August 2015 in English (English)

There is a proposal to change the rendering of footway and path so that they basically look the same in the default OSM rendering.

https://github.com/gravitystorm/openstreetmap-carto/pull/1713

I fully support this.

Perhaps, this is the best way that widely used, but confusing and redundant tags such path/footway are rationalized. Basically, give up, declare them synonyms, and render based on dependent/sub tags. Our limited energy can be used on better tags such as surface, designated, access, foot, pet, etc to describe this thing you can walk on in more detail.

Releasing GraphHopper 0.5

Posted by karussell on 12 August 2015 in English (English)

Today we are proud to release version 0.5 of our open source road routing engine GraphHopper. Try it out on GraphHopper Maps and read more

graphhopper maps route planner

We’ve improved the GraphHopper core and the GraphHopper Directions API which now includes route optimization.

Карти Рудно / Суховоля

Posted by SaniLitv on 12 August 2015 in Ukrainian (Українська)
Older Entries | Newer Entries