OpenStreetMap

Diary Entries in English

Recent diary entries

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?

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

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.

Why am I against wholesale import of administrative boundaries from any 3rd party source for the Philippines

Posted by maning on 11 August 2015 in English (English)

Disclaimer: This is specific to the Philippines, not a general OSM issue.

One of the most difficult data to collect in OSM are administrative boundaries (admin_level=*). It defies the on-the-ground rule. One cannot just go out and start surveying admin boundaries with a GPS. On the other hand, we see the importance of having admin boundaries in our database. We can define town/city limits. It improves geocoding. The maps looks nice. Humanitarians need them because they can plan and allocate resources according to administrative jurisdictions during a crisis. The only logical way to have this in OSM is to get them from various sources and do an import.

The most comprehensive source we found for the Philippines is from the freely available GADM. This website has a comprehensive collection administrative boundary data for free down to the smallest administrative units for many countries including the Philippines. Over the years, I tried to track down the provenance of GADM’s PH data. My geo-forensic skills lead me to people saying that the PH dataset originated from our national mapping agency. So, it seems very authoritative, why don’t we just import them? I say NO and here’s why (again, I am pertaining here to the Ph situation, GADM data maybe good in other countries and I have the utmost respect to the maintainers of the site sharing this to the public).

The license is incompatible. Period. End of discussion. Eugene discussed this years ago in our mailinglist.

Even if the license is compatible, the data quality is REALLY bad. Again, from Eugene’s mail to the list, here’s screenshot comparing OSM and GADM boundaries in Quezon City.

qc_gadm

If the above arguments does not dissuade you, consider this story.

Administrative boundaries imply a level of authoritativeness in the data. Ordinary users of the data may take it as exact and definitive. For example, during the immediate relief operations after Typhoon Haiyan in the Philippines, OSM volunteers across the world participated in the remote mapping response. We generated a tremendous amount of building, roads, and landuse data which were used by many international response agencies. Since we lack and can’t remotely map admin boundaries in the affected areas, response agencies resorted to using 3rd party admin boundaries (GADM is one of them) as an overlay to OSM derived basemaps. These maps were used by humanitarian agencies to organize relief operations. When I went to the affected areas months after the Typhoon, local authorities are complaining that in some instances, international agencies are insisting in their own maps particularly the village boundaries as a basis of relief supplies allocation. Local authorities would insist that these boundaries are wrong and does not exist in reality. Of course, response and relief planning should be dependent on other factors and not just based on a map, but, a wrong map exacerbates an already confusing situation.

So am I saying that we shouldn’t be adding admin boundaries in the Philippines? No, what I’m saying is that any 3rd party admin boundaries that covers the whole country you stumble upon either from the internet or directly from various agencies are wrong. No comprehensive data exist in the Ph.

What can we do now?

Talk to your local government authorities. You may find good data from specific local government units, if ever you get a hold of such data, let us know and if it is good enough, we can start the process of adding them in OSM.

Go out and survey! Map places as nodes. Oftentimes, a place node (place=town,city,village) is enough. For finding places in OSM, would you want a geocoder to give you a wrong boundary/polygon or a node/point that tells you exactly that this place exist in reality? In many cases, this is what I’m trying to do. Here’s a screenshot of village nodes we mapped in a remote town in Leyte. Compare that to the inaccurate (by 3 kms south) imported boundary of the town. Unless we get a better source to replace this boundary, I would rely more on the place node we surveyed with the local community.

burauen

I know, sometimes, it is very frustrating, OSM is heralded as one of the best freely available geographic data, yet, we lack the most basic admin boundaries over many areas. Imports might be the immediate solution, but, I ask PH mappers no to do this. I’m fine with missing boundary data for now, in time we can improve this the OSM-community-way, by importing, we maybe propagating more errors rather than helping improve our map.

Location: Jaro-Dagami-Burauen-Lapaz Road, Poblacion - District 5, Burauen, Leyte, Eastern Visayas, 6516, Philippines

New road style for the Default map style, the full version - high zoom

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

highway=pedestrian/living_street is this comparison was set to pale gray/gray version. Reported problems were fixed, resulting in new shield colors, tweaked road color and subtler casings. Thanks for the feedback!

This comparison is using latest version of style, newer than one used on the OSM website. The most important change is the new forest style.

For start: place that had problem with too strong casing resulting in problems with bridge that was not sufficiently different from other sections of roads. It is now improved - and now it should be OK.

What is preferable? Large images or smaller ones next to each other (like in the previous entry)? Or maybe big pictures next to each other - but available as links and not inlined (like many in this older entry)?

Problems

Default OSM style is displaying huge amount of information. Here is image of displayed road types on some of landcovers. Note that due to size limitation effects of service tags (that would tripple different road styles) are not displayed.

Full image

New road style fixes problems with certain road types invisible on common landcovers, but there are still some situations where road is too close to landcover. Unfortunately, as result of huge amount of landcovers it is not easily fixable - but new problems are a bit less severe than old "trunk is invisible in forests, secondary is invisible on farmland".

highway=motorway through landuse=military is poor

highway=secondary shield is almost the same as the heath color

highway=secondary is close to natural=beach

Mapping Party in Butuan, Agusan del Norte

Posted by maning on 10 August 2015 in English (English)

Last July 24-25, we had the third leg of the series of crowdmapping events co-organized by The Asia Foundation (TAF) and its local partners in Butuan City. The first was in lloilo and the second in Tagbilaran. Similar to the previous events, the objective of this mapping party is to increase awareness of the potential of using OpenStreetMap to complement the various mapping initiatives of the TAF’s local partners in the region by inviting mapper volunteers to participate.

butuan mappers

Butuan is a special place for me. I have never been to this part of Mindanao, but, this is where the journey of my relatives may have started when my grandfather and his family migrated from Luzon and started a new life to what was then called the “new frontier” of the Philippines 4 decades ago.

Butuan is also a significant trading port during the pre-colonial times. Within the alluvial plains of Agusan river, archeologists discovered remains of pre-colonial settlements serving as a major trading and inter-cultural exchange between the upland tribes of Mindanao to Indonesia and mainland Asia.

In the late 1970s, remains of balangay boats within a dried-up river channel near the city centre were discovered.

balangay remains

“The balangay was the first wooden watercraft excavated in Southeast Asia and is evidence of early Filipino craftsmanship and their seamanship skills during pre-colonial times.” Wikipedia.

balangay replica

A proof that early Filipinos are excellent sea navigators and have sustained trading relations with the rest of Asia even during pre-colonial period. The word balangay is where the word barangay originated. It is the smallest administrative division of the Philippines (place=village, admin_level=10).

Moving on with the mapping, I arrive Butuan early morning of Friday. The orientation to participants will start later in the afternoon. With nothing else to do, I explored the city on foot with my GPS and camera taking several geotagged photos for my own mapping including a mapillary sequence of the mighty Agusan River.

agusan river

Later in the afternoon, we started the orientation to the local cycling group and instructed them to download OsmAnd which they will use for the field mapping exercise the next day.

osmand download

We started early morning of Saturday to the usual meeting place for bikers, after a few minutes of basic OsmAnd use, the teams proceeded to their assigned patch to map POIs focusing mainly on 24/7 and cycling related facilities.

osmand in the field

We met again for lunch and uploaded all our collected data. We mapped around pois: 435, lines: 40, polygons: 27 during the day and I’ve seen a few mappers continue adding more POIs a week after the event.

The cyclists really love OsmAnd because it is not only a data collecting app but more importantly, a complete offline navigation app they can use for their regular rides. One thing I noticed is that with the ever increasing size of data download for the PH maps in OsmAnd, it is starting to be very difficult to download for areas with very slow connection especially in remote areas and even in major cities in Mindanao and Visayas. Expensive data plans were maxed out just to download the worldwide overview map. I’ve already posted an GH issue hoping the OsmAnd devs would consider splitting the PH map into subregions just like other countries.

As usual, notes, photos and map updates in this page: http://maning.github.io/taf_crowdmapping/butuan.html

Location: Glenn Ivy Homes Subdivision, Butuan, Agusan del Norte, Caraga, 8600, Philippines

Belgian Mapper of the Month : Matthieu Gaillet

Posted by escada on 10 August 2015 in English (English)

Matthieu Gaillet is a technical electrician and is now responsible for the technical aspects in a cultural center. His motivation to map comes from his passion for collaboration in map making and his intensive use of maps for cycling and hiking trips.

Matthieu Gaillet

Where and when did you discover OpenStreetMap ?

Just like everybody else probably: by accident, in 2010 :-) I immediately liked the concept of a map created by collaboration. But at that moment I was not completely convinced that the project would become popular and accepted enough to compete with Google maps. Since then I started using open source based servers and software and the virus got me. It was not before 2013 that I started using OpenStreetMap and my first contributions with JOSM are also from that time.

Do you use OpenStreetMap yourself ?

I use it both privately and professionally, mainly since the arrival of Mapbox, umap, etc, since it is now possible to personalize maps.

Which type of mapper are you ?

I use my own GPS-traces and I have the habit to map a couple of hours after returning from a trip. Since I use OpenStreetMap-based maps, I tend to leave my planned route to do some improvised surveying and have the intense pleasure of adding a missing trail to the map. I am also an armchair mapper and base myself on information published by third parties. Because of this, I sometimes act as an improvised open data evangelist when public services are deciding whether or not they should release their data. My favorite areas correspond to my interests and places I go. Thus I have "committed" a lot of changes along the Eurovelo 6 cycle route that passes through Europe, all the way from Germany to the Black Sea (Romania).

What do you map ?

I concentrate mostly on footpaths and cycling facilities.

What is your biggest achievement as mapper ?

That would be relation 4128428. It represents the large cycle network “La Wallonie Picarde à Vélo”, which is put into place and published by SPF Wallonie, more specifically the intermunicipal IDETA. It contains 687 nodes and 914 routes. I started working on the network in mid 2014, after getting a written authorization from the IDETA. Little by little, evening after evening, I did about 75% of the network. And then IDETA came back to me and asked me to sign a document completely incompatible with the Openstreetmap ODbL license.

So I became an open source evangelist. Until now without much success, but I'm stubborn :-) Meanwhile, I obviously had to stop my work on the dataset, which had already cost me an enormous amount of labour time.

Mapping the network also forced me to master JOSM, which is not to be taken lightly. To be frank, I hate JOSM as much as I love its power. It is not user friendly enough, performance isn't great, user interface looks a bit early nineties. But for advanced mapping task, there is no alternative - and it does the job rather well.

Another nice moment was when the city of Brussels completely changed the traffic plan in the city center. A whole area became pedestrian and a parking route was introduced, which affected quite a number of streets. I prepared the changeset a couple of days in advance. I was planning to update the map on the very second at midnight when the change came in effect, but other mappers advised me to do it a few days in advance, to avoid having to resolve too many conflicts in the map. So we can surely say that OSM really was the very first map to be up to date :-)

Why do you map ? What motivates you ?

Out of passion, and because I find it extremely rewarding that many users can freely use the results of a hobby. I am thinking of hikers that come from the other side of the world who can plan their trip on a path that I have mapped. I really like the utopian and universal aspects of this type of projects.

Do you do other things besides mapping ?

Occasionally, I update the wiki. I also help other users that I encountered in the course of my virtual wanderings to map more complex things. I intend to organize a survey party of Brussels cycling facilities.

Do you have ideas to grow the OpenStreetMap community, to motivate more people to start mapping ?

Openstreetmap.org could do with a better user interface. At the moment, I don't feel that it does justice to the quality of the data behind it. iD is a great tool, that only needs to keep widening its scope.

What is the largest feature of OpenStreetMap?

Being universal, and being able to adapt to the needs of mappers.

What is the biggest challenge for OpenStreetMap?

Becoming indispensable, and much more visible by having its data integrated in more external party's apps.

How do you keep up-to-date on OpenStreetMap news ?

The mailing list and the virtual newspaper weekly OSM, which I discovered via the mailing list.

Do you have contact with other mappers?

Of course ! Especially with Polyglot, who I consider my mentor as he makes it a point of honor to share his knowledge particularly in terms of public transport networks..

To conclude, is there anything else you want to share?

As is often the case with open source, different clans clash, thereby losing a lot of time. I think for example that the teams behind iD and JOSM should try to join forces: there is a lot of redundancy. That is a pity. On the (Belgian) mailing list, the tone is not always pleasant. A moderator should intervene when things get out of hand. But lately it has calmed down :-)

highway=trunk infestation in San Paulo

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

To anybody editing in region of San Paulo - it seems that road classification in this region is thoroughly broken (many highway=trunk that probably should highway=tertiary/secondary given how road ends etc etc). It seems that somebody tagged all dual carriageway roads in this region as highway=trunk.

I opened also some notes - is there any better method of contact with local community?

http://www.openstreetmap.org/#map=11/-23.6260/-46.6878 http://www.openstreetmap.org/#map=19/-23.47256/-46.62624

Location: Santana, Mandaqui, São Paulo, Microrregião de São Paulo, RMSP, Mesorregião Metropolitana de São Paulo, São Paulo, Southeast Region, Brazil

New road style for the Default map style - the full version

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

Next stages of developing new road style are finished.

First changes all already present on OSM website as result clutter on mid zoom levels is now reduced (#1682, #1690 and #1676).

This version is the first one tested also for low zoom levels.

And at start of this preview of the new style I want to thanks everybody who offered feedback. Obviously, not every suggestion was implemented - but many were highly useful and some are used. Thanks to everybody! Special thanks to Paul Norman for simplified osm2pgsql database dump that allowed to test low zoom levels.

For start - rendering for http://www.openstreetmap.org/#map=10/50.8302/4.4769 both in current and the new style (note - missing data that is causing poor rendering of railways in Antwerp is now fixed).

z11 50 8288 4 3684 z11 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z11 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z10 50 8288 4 3684 z10 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z10 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z9 50 8288 4 3684 z09 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z09 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z8 50 8288 4 3684 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z08 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z7 50 8288 4 3684 z07 750px c6942c7a16fbd8f0048a8be8d7bf3703243b02e1 750px

z6 50 8288 4 3684 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px 50 8288 4 3684 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z5 50 8288 4 3684 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px 50 8288 4 3684 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

Auckland

z5 -36 8487 174 76135 z05 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px -36 8487 174 76135 z05 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z6 -36 8487 174 76135 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px -36 8487 174 76135 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z7 -36 8487 174 76135 z07 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px -36 8487 174 76135 z07 750px c6942c7a16fbd8f0048a8be8d7bf3703243b02e1 750px

z8

-36 8487 174 76135 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z08 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z9 -36 8487 174 76135 z09 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z09 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z10 -36 8487 174 76135 z10 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z10 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z11 -36 8487 174 76135 z11 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z11 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

And yes, this volcanoes are tagged correctly - see https://en.wikipedia.org/wiki/Auckland_volcanic_field

Malmo

Place mentioned in bug report #102 - "Secondary and trunk color too similar to landuse colors"

z5 malmo - fields 55 39276 13 2979 z05 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z6 malmo - fields 55 39276 13 2979 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px malmo - fields 55 39276 13 2979 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z7 malmo - fields 55 39276 13 2979 z07 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px malmo - fields 55 39276 13 2979 z07 750px c6942c7a16fbd8f0048a8be8d7bf3703243b02e1 750px

z8 malmo - fields 55 39276 13 2979 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z08 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z9 malmo - fields 55 39276 13 2979 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z09 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z10 malmo - fields 55 39276 13 2979 z10 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z10 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z11 malmo - fields 55 39276 13 2979 z11 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z11 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

Preview location from readme

preview pri7 -87 6515 41 8693 -87 615 41 8788

Current style:

Railways

One of changes that I especially like are new railways - now less likely to be confused on low zoom levels with minor roads. service tag is now used more for railways - minor tracks are rendered later (change already deployed on OSM website) and now main railways tracks are also more prominent. Tunnels for railway=rail also were changed to version that is prettier and consistent with other railway tunnels.

Here are some additional examples with comparison how railway rendering may change.

london - railway tunnel 10 19 master - master 400px london - railway tunnel 10 19 new-road-style - new-road-style 400px

krakow - minor major railways 10 19 master - master 400px krakow - minor major railways 10 19 new-road-style - new-road-style 400px

highway=pedestrian, highway=living_street

I have a problem with colors for these road types. It is desirable to keep these distinguishable, using white colour and differentiating by width is not feasible.

Current colors are quite confusing - OK, highway=pedestrian is a bit darker. Then why living street - something between highway=pedestrian and normal streets is even darker?

The obvious solution - switch colors is problematic, as it makes squares really ugly:

vatican - square new-road-style -_ new-road-style 17 17 new-road-style - new-road-style 350px london - trafalgar square new-road-style -_ new-road-style 17 17 new-road-style - new-road-style 350px

It is possible to make both living street and pedestrian lighter.

vienna - square around church in the cetrum megacollider -_ megacollider 17 17 megacollider - megacollider 350px

but it makes highway=pedestrian and landuse=residential areas too close:

conflict with landuse residential - orchester megacollider megacollider-_megacollider 17 17 350px megacollider - megacollider 350px

Reddish highway=pedestrian was promising

living street pedestrian red -_ red 17 17 red - red 350px

until it turned out that it collides with other landuse

test_pedestrian_on_industrial 1 red red-_red 17 17 350px red - red 350px

Other PRs

During work on road rendering I discovered that map would look better with some landuses becoming lighter and less saturated. Therefore I slightly modified old proposal to modify rendering of forests and submitted it as #1728 (I opened a new PR as code needed to be updated).

There is an open PR that would unify highway=path and highway=footway styling and show surface for highway=path/footway/cycleway - #1713

There is also a PR that would improve rendering of highway=raceway: #1712

Also there are also PRs that would make farmland and power areas less prominent - see #1701 and #1680.

During development of road style some long-standing bugs were sufficiently annoying to prepare code fixing this issues. Once test images will finish generation I will send also fixes for #1143, #686 and part of #1648

Merged

Some other minor changes like tweaking display of steps will be present in the next release https://github.com/gravitystorm/openstreetmap-carto/pull/1714

selection_001

It is quite interesting - some changes are quite simple, like in this case. Entire PR was changing only one number. But preparing even such easy changes without causing problems requires testing many locations and weird situations to avoid unexpected reducing in quality of rendering. In that case during preparing I tested several other variants - maybe even smaller (it was no longer looking like steps)? Maybe increase distance between red dashes (it no longer looked like a single element)? Maybe make red dashes narrow (it was not noticeable enough in typical cases)? Maybe reduce width but not so much (it was worse in areas of high steps density without benefit for typical situation with single steps in areas).

How do you map while on the go?

Posted by mvexel on 8 August 2015 in English (English)

I don't do a lot of 'on the go' mapping. I have tried a lot of the tools out there that should help me do that: KeypadMapper, Go Map!!, Vespucci, Pushpin, OsmAnd. Most of these are way too convoluted for me. When I am out and about, I just want to make a quick edit - usually a POI of sorts - and move on.

Pushpin and Go Map!! come the closest to what I want. Both are available for iOS only, I think. (Do Android users not like simple editing tools?) They let me quickly add a node and upload it to OSM. Or add some tags to an existing one.

Still, what I end up doing most is just taking pictures with my phone. Lots of them. I try to get both overview and detail. I end up with a collection of images like this one here from right before I moved to the US.

collection

When I get home, I copy all the images to my computer and load the entire directory into JOSM. It will put the image locations on a map. I can cycle through them easily and map what's on there using all the convenience of JOSM.

editing

The only thing you need to verify is that your phone saves the location with the image. This is on by default on most phones these days.

How do you prefer to map while on the go?

Map evening in Bengaluru: The open mapmakers guide to life

Posted by PlaneMad on 7 August 2015 in English (English)

Not usually do I look back, but this has been a fun path. Its been over 8 years since I accidentally hit the edit button on this interesting project called OpenStreetMap during my student years creating maps of India on Wikipedia.

untitled

There's been some interesting incidents, people and epiphanies on this rather eventful journey, a spicy cocktail of open source, geography and life in India. My contemporary @geohacker and I were somehow sucked into this crazy world in our own ways in different places, our passion driven by this common conviction that being open is right, and that maps can change lives, and be beautiful and inspiring, just like art.

As it were to happen, both of our paths eventually intersect at this rather inspiring bunch of people who call themselves Mapbox. Both our journeys have been different, but there has probably been something in common. To speak our hearts and fighting this addiction with open source maps, we invite you for an open house at Mapbox Bengaluru.

Date: Monday, 10th August 2015 Time: 7:00 pm

See you there, bring those who are close, and open!

Location: Indiranagar 1st Stage, Indiranagar, ಬೆಂಗಳೂರು, Bangalore Urban, Karnataka, 560038, India

Tag-only editing with Vespucci

Posted by SimonPoole on 7 August 2015 in English (English)

No, this is not news. Vespucci has had a tag-only mode since its original creation in 2009, however since the old very modal user interface hasn't been the default UI after the work by Jan Schejbal in 2012 and the start of the 0.9 releases, it hasn't really been easily accessible.

Starting with 0.9.6 tag editing only mode can be switched on with a long press on the lock icon.

vespucci can still be locked/unlocked with a normal single touch on the lock and a long touch will get you back to normal editing mode.

Now while I personally don't quite see the utility of such a mode, users have asked for it and it is the only remains of the old modes that will survive in 0.9.7. In any case it is light years better than the many apps of different kinds that claim to offer simple editing but in general are survey apps on steroids that mess up existing data.

Simulate traffic using OpenStreetMap-data and SUMO- Simulation for Urban MObility.

Posted by jinalfoflia on 7 August 2015 in English (English)

SUMO is a free and open traffic simulation suite which is available since 2001. SUMO allows modelling of intermodal traffic systems including road vehicles, public transport and pedestrians.

  • This simulator has many options to customise the simulation, options like CO2 emissions on roads, speed limits of the roads etc
  • The data for simulation is taken from the OpenStreetMap

Some useful links to help installation of SUMO simulator for

Steps to simulate traffic of a particular region.

Step 1: Download OSM data from Open Street Maps (<file_name>.osm)

Step 2: Run this command to get the .net file required for simulation. (Netconvert imports digital road networks from different sources and generates road networks that can be used by other tools from this package.)

netconvert --osm-files <file_name>.osm -o <file_name>.net.xml --output.street-names true --output.original-names true

Step 3: From the following link copy the additional polygons structures

http://sumo.dlr.de/wiki/Networks/Import/OpenStreetMap

Step 4: Save the data into a file and name it as 'typemap.xml' then run the following command. (Polyconvert imports geometrical shapes (polygons or points of interest) from different sources, converts them to a representation that may be visualized using SUMO-GUI)

polyconvert --net-file <file_name>.net.xml --osm-files <file_name>.osm --type-file typemap.xml -o <file_name>.poly.xml

python /Applications/sumo-0.23.0/tools/trip/randomTrips.py -n <file_name>.net.xml -e 100 -l

python /Applications/sumo-0.23.0/tools/trip/randomTrips.py -n <file_name>.net.xml -r <file_name>.rou.xml -e 100 -l

  • After the above steps, the routes have been generated, in the xml file you need to configure the file for the SUMO gui

Step 5: Search for the sumo.cfg file in the sumo folder and copy it to your working folder.

The configuration file should be modified with the following contents:

<input>
    <net-file value="<file_name>.net.xml"/>
    <route-files value="<file_name>.rou.xml"/>
    <additional-files value="<file_name>.poly.xml"/>
</input>
<time>
    <begin value="0"/>
    <end value="1000"/>
    <step-length value="0.1"/>
</time>

Step 6: To run the simulator

sumo-gui <file_name>.sumo.cfg

Outcome

sumo

  • Helps one understand how each tag that we use impacts the traffic.
  • Helps in, in-depth analysis of the road network that's established by the OSM data.
  • It by default simulates right-hand driving traffic conventions and has no options for left-hand driving conventions.

For more questions.

Older Entries | Newer Entries