Recent diary entries
I would be mapping my surrounding area at Ebute Meta LSDPC.
Starting for the religious building such as mosque, churches and mechanic workshops.
I started making a mapped directory od self-organized solidarity initiatives in Thermaikon area. Any help will be appreciated.
Redundant or weird tagging?
Sometimes we have to tag a shop without knowing what kind of shop it is. Then we use: shop=yes.
If you know the shop is a clothes shop, then shop=clothes would suffice. Using amenity=shop as in the example below is not encouraged: My advice is to clean-up such tags whenever you encounter them.
The next examples left me puzzled:
Is there really a jewelry in that bar?
What does amenity=printer mean? Can you buy a taxi in that shop? Does it come with the driver?
I used openpoimap for all the examples with this code:
which translates in: "find all nodes\ways\relations\ that have both an amenity key and a shop key, irrespective of value of that key".
Try it out in your own area!
As I removed in changeset 32842753, there are way too much Korean(English) which can be changed to use i18n correcrly.
I'm gonna do where I can but wtf it's so YOOOOOO.
I don't suppose it's of use to many people, but in the interests of adding to the list (somewhere) of software-that-supports-OSM, here's one more: http://samwilson.id.au/2015/07/23/tabulate/
Or on the WordPress plugin directory: https://wordpress.org/plugins/tabulate/
Yesterday I was out mapping the disc golf course on I20 in Umeå, I'm learning relations and general mapping best practices.
I'm also starting to get a feel for Leaflet, Overpass and other libraries/APIs which will be good when visualising my edits.
Note: I don't actually play disc golf myself.
To work better and safer in localities where a good identification of the mapper as a harmless person is advantageous, I made a "mapper´s shirt" in portuguese. Anyone who needs the files (front and back side, *.png and *.svg format, without the mapaitapetinga.com.br URL) to reprint your personal shirt in a local shirt manufacture, please send a message to my user account informing your mail adress.
Got a little bored of mapping the back country of Chiapas so i began mapping Las Margaritas which i had started about a year ago but only placed a few of the many streets. I have now finished 2 out of the 4 main street quadrants. I am choosing to map it like this because the street names are divided into 4 quadrants. Once I complete the main streets within the city I plan to move to map the surrounding area and towns from Las Margaritas.
I may return to the Backcountry of Chiapas before I completely finish the Las Margaritas area. staying in one place too long can get boring.
"map styles: Default OSM vs Google Maps" included comparison of OSM Default map and Google maps. Now I present a similar comparison at the same location. But now with a third version - current version of new potential road style.
From left: (1) with changes developed as part of road redesign (2) currently used rendering on OSM website (3) Google maps
Maybe it would be a good idea to make landuse=residential darker on low zoom levels to better mark built up areas, but overall I consider this change as significant improvement.
Changes based on feedback:
Thanks to daganzdaanda for the idea of displaying highway=tertiary as white line, wider than highway=residential/unclassified. As tertiary roads are no longer using yellow it made possible to display secondaries using this color, what it turn allowed to move hue of primary toward yellow.
It was not simple as it sounds. For example, one of obvious consequences is that yellow roads are now rendered also on lower zoom levels. It is problem because the yellow roads are hard to keep visible both on landuse=farmland and unmapped land. For example using light yellow worked great on farmland but completely failed on unmapped land where it was really hard to notice.
Making highway=primary yellower allowed to render trunk in orange and keep road classes possible to differentiate.
So: highway=trunk and highway=motorway are now rendered differently.
See for example highway=trunk near Košice and D1 motorway.
and now with the new style. Game "spot highway=trunk" is now less challenging and it should be distinguishable from motorway.
And view at the preview location from readme
Using a grained fill pattern to indicate unpaved roads is an interesting idea that will be tested. I will also test idea of using dashed casing for unpaved roads with tunnels marked solely by colour change of fill and casing. There was also idea of displaying tunnels as without fill what is also worth testing - but it is likely that displaying unpaved roads as one with dashed casing and fill would be too close. Also, size of ref shields should be reconsidered - it seems possible to make them small without losing readability.
There are also changes to how railway are displayed. Some improvements of rendering railway=tram will be used after next update of map style on OSM servers. But there also problems with rendering railway=rail - both major and minor (marked by service=spur/siding/yard) rails are rendered really close. At lower zoom levels rendering of railway=rail is really close to rendering of minor roads.
I am experimenting with changes to rendering of railways. Some changes are ready to presentation and effects are visible on presented examples.
I am trying to find as many improvements as possible that may be proposed, discussed, improved and accepted as an isolated change. It makes discussion easier and bugs are less likely.
Turning circles on highway=track are no longer too big, code was improved. In addition highway=proposed is no longer rendered (for discussion and reasoning behind decision see https://github.com/gravitystorm/openstreetmap-carto/issues/1654).
Currently proposed changes
There are also active pull requests, some of mine are done as part of road redesign. For example there in pull request proposing better display of minor tram tracks It is open question whatever railway=tram with service=spur/siding/yard should be rendered on z14 and z15 - feedback is welcomed (more locations with rendered before/after are listed on github).
Examples of current work
Stopping too early rendering of highway=residential allows to achieve improvements like demonstrated in the first picture demonstrating changed rendering in London. But ceasing to render highway=residential on zoom levels 12 makes noise created by small buildings noticeable. These buildings are too small to be rendered in useful way but big enough to create noticeable changes.
The simplest solution would be to start rendering buildings from z13, one zoom levels later. But some of largest buildings may be usefully rendered on z12. Also, as usually there are additional complications (for example - moving only rendering of buildings to higher zoom level is not enough - it is necessary to move also rendering of amenity=place_of_worship).
On the left - current style. On the right - new style, including removal of highway=residential on this zoom level
And three examples of buildings may be handled:
stop rendering of all buildings (even the largest ones)
stop rendering of small buildings (threshold is arbitrary what is quite noticeable. In many places it is clear that some buildings are rendered and some not despite nearly the same size)
render only big buildings on z12 (my favourite - but it still arbitrary threshold and some big ones will not be rendered. But as rendered buildings are quite rare it is not so noticeable)
OSM Ottawa, Summer Meetup will happen 1900 hrs, 24 July, @ Second Cup, 379 Richmond Road, Ottawa, ON https://www.openstreetmap.org/node/1649622919#map=19/45.39142/-75.75575&layers=N
Denis: Will give a 30 min talk on how he used OSM during his 30 day deployment to Nepal as part of the DART. Tom: Will talk about mapping Ottawa heritage John: Will talk about Mapillary and handout some Mapillary swag.
Once again, we had another mapping event. This time, in Tagbilaran City, Bohol. This is part of the series of crowdmapping events co-organized by The Asia Foundation and its local partners. The first was in Iloilo City last May 2015.
During the event, Bohol Governor Edgardo Chatto welcomed all the mappers and expressed his support to implement this initiative for the whole province of Bohol.
Bohol's major income is tourism. However, when the 7.2 earthquake hit the island in 2013, the tourism industry was heavily affected. On the other hand, judging by the number of tourists (local and foreign) who was with me during the flight, I think tourism is now recovering. What a better way to help by providing a good map not only for the tourists but also for the local community!
The local partner of The Asia Foundation is the local chamber of commerce. Naturally, we focused on collecting business and tourism related map data during the field exercise.
Using phones powered by OSMAnd, we collected and updated pois: 451, lines: 94, polygons: 168.
I joined one of the field teams and also took the opportunity to kickstart crowdsourcing streetviews using Mapillary.
Other than several hiccups with the internet, the organizers did a very good job in managing the event. I hope the map data we collected will help in expanding the mapping community and help the province in revitalizing its tourism industry.
More notes/photos and map updates in this page: http://maning.github.io/taf_crowdmapping/tagbilaran.html
Rendering surface value should reduce prevalence of using highway=track for any unpaved road. Unfortunately currently this tagging for renderer is really popular.
There are various styles typically used to depict important low quality roads:
(1) lack of fill, only casing is displayed. But it works well on maps where most roads are OK, and only some are of low quality (typical for maps of Australia with unpaved roads across the outback). In areas where all or nearly all roads are unpaved results would be weird - roads render as thin double lines. Also, there would be problems with OSM data model, as rendering of crossings and places where way is split would be poor
(2) lack of casing or dashed casing - this style is currently used for tunnels. It would make necessary to find a new style for tunnels what is not easier. Also, people would be highly confused by using of tunnel style with a new meaning.
(3) dashed fill (normal road colour & special colour) - it is style that seems the most promising and examples below show how it may work. Roads under contruction are currently using this style - it is also necessary to change it.
(4) new separate colours of fill/casing - changing only casing is not really noticeable and/or is ugly, changing colour of fill doubles number of road classes that should be distinguishable. What worse, unpaved and paved of the same class should be similar what is quite hard to achieve. This differentiation is used really rarely, with Humanitarian style as the most prominent example.
(5) display in style similar to current highway=track - this style is not working well for important roads of a low quality (there are situations where [highway=primary; surface=unpaved] is used)
(6) dashed casing & fill (normal road style & empty space) - this style works better for roads under construction. highway=construction may start using such style
Styling of unpaved roads should:
- introduce easily noticeable difference between paved and unpaved roads
- do not introduce highly busy styling
- make clear that unpaved road is worse than paved road
- do not make unpaved road more noticeable than paved one
- keep unpaved and paved road of the same class similar
on the left - current rendering, on the right possible new rendering
But situation is further complicated by fact that some roads are unpaved with set access=no/private/destination. Ideally it would be clear whatever given private road is also paved/unpaved. Unfortunately this part is not really successful.
On map above it is not immediately clear which road, if any is unpaved.
But in case of private roads it is more important that there is no access than surface value and unpaved roads with access=destination are quite rare so maybe this problem is outweighed by rendering surface value.
One thing that remains to be adjusted is how prominent dashes should be. Below are sets of images with various intensity of dashes. For each location there are four images
left: current rendering right: light dashes
left: light dashes right: moderate dashes
left: moderate dashes right: strong dashes
left: strong dashes right: really strong dashes
Unpaved primary road
City with some unpaved roads
Unpaved service roads. Such roads are very often mapped using highway=track
Paved and unpaved raceways.
City with curvy unpaved roads
Unpaved road with access=private
Unpaved road in the city
Unpaved road in suburbs
Unpaved roads in a village
Unpaved road with access=destination
Unpaved tertiary road
Currently I am planning to use moderate dashes.
Differentiating highway=trunk and highway=motorway
I am working on two version of differentiating of these road types. First keeps all road types in in white-yellow-red gradient, with an additional road class. Second is based on the German map style. Unfortunately, after days of tweaking I am still unhappy about results so I decided to avoid publishing preview.
highway=residential on z12?
flohoff proposed to keep highway=residential on z12
I love the z10 z11 residential road change. I'd like to keep them in z12 for the moment. Residentials often make one get an impression on residential areas and population density. That would get lost.
From my test (some comparison images are linked below) - rendering highway=residential on z12, less prominent than highway=unclassified improves map for locations without mapped landuse=residential. But for places where landuse=residential is mapped it is better to not render these roads.
A new long-term version of osm2pgsql has been released, 0.88.0. This includes the work done in the 0.87.x development series and the porting to C++.
Like all versions, 0.88.0 can be obtained from https://github.com/openstreetmap/osm2pgsql
Potentially breaking changes
A database reload is recommended. If not, the schema migrations in https://github.com/openstreetmap/osm2pgsql/blob/master/docs/migrations.md are required.
Osm2pgsql is now C++ and requires the Boost libraries. Build scripts and package dependencies may need adjustment
Major new features
- A new backend has been added, the “multi” backend. This allows multiple tables which can each contain different types of features. More documentation is available at https://github.com/openstreetmap/osm2pgsql/blob/master/docs/multi.md.
One potential use for this feature is matching an existing schema for data, to allow OSM data to be a drop-in replacement.
In-memory pending tracking instead of in-database, with significant performance gains.
Rendering tables are ordered by GeoHash when created, resulting in significant performance improvements.
z_logic has been improved, taking into account more recent work across multiple styles. https://github.com/openstreetmap/osm2pgsql/pull/374 has more information.
The node storage has been improved, and out of order nodes and nodes at 0,0 should now always be handled correctly
A new test suite with unit tests
Many bug-fixes and cleanups
- Append mode is not supported with non-slim. This is suported in 0.89.0-dev, but is frequently a user error. Typically, when a user does this they should instead merge input files with osmosis/osmconvert and use --create
osm2pgsql is switching to libosmium for parsing and will require a C++11 compiler. These changes are already in 0.89.0-dev. Beyond this, it depends on contributor time and interest and if anyone decides to pay for development.
Mailing list post: https://lists.openstreetmap.org/pipermail/dev/2015-July/028641.html
[DRAFT - IN PROGRESS]
This reports the findings of a brief feasibility into the use of satellite night-time imagery data to aid the identification of rural settlements for humanitarian mapping purposes. The data in question is from the US Government's Earth Observation Group. I thought two products looked potentially useful: listed as Visible Infrared Imaging Radiometer Suite (VIIRS) and Defense Meteorological Satellite Program (DMSP). DMSP-OLS is a composite of visual imagery that's been filtered for e.g. cloud cover and moonlight interference (see metadata). VIIRS searches a specific spectral band to identify night-time fires, and comes both as a composite raster surface and a daily list of discrete points of identified fires.
To evaluate these I compare them to the OSM buildings layer of Unity State in South Sudan*, which was recently augmented quite thoroughly by a Missing Maps mapathon. The various EOG datasets come in tiff, png and kml formats, and have been visualised using R. The code for importing, reformatting and plotting the data is posted at Github. Results follow:
First a code demo - plotting the crop of London from the same data:
- obtained using the HOT Exports utility
Looking into what geographic data already exists, I came across this South Kivu map by RGC. It is six years old (mise en carte 2009) and offers an overall perspective of the southern region.
RGC (Referentiel Geographique Commun) was created to "avoid dispersion of data, redundancy of actions and incompatibility of sources". It is administered by two DRC national institutions and many are the members/producers of data (Cluster Logistic, MONUSCO, UNMACC, OSFAC, UNOCHA, UNOPS, ISCO, etc).
The positive side is that the sources are many so perhaps this map could be used as a starting point for mapping the region with more accuracy. The negative side - and major problem - seems to be a lack of validation on the field, which affects its quality.
Has anybody used/seen this map before?
As part of the planning for mapping South Kivu, the Disaster Mappers (and particularly a guy called Benni) have been developing a new microtasking platform for identifying human settlements and road networks before we go anywhere near the tasking manager.
This has been designed for two reasons. Firstly, so mappers don't have to spend hours scanning through the many, many, many square kilometres of jungle that exist in the province. The second is that, by using a much simpler tool for recognition of features, we hope to be able to engage a whole new audience of collaborators. People that might not want to learn iD - or might only have five minutes to spend. If they can do this painstaking work in a relatively easy (and fun?) way, it leaves mappers to... well, map.
Benni's first try at this was great, but we knew it could be better. We sent it out to the Humanitarian OpenStreetMap Team list and got some great feedback.
Now there is a version 2. Benni says he has taken this about as far as his skills allow and is asking for help to finish it off. If anyone is interested in collaborating on this, please get in touch by leaving a comment or by tweeting at Missing Maps.