Greetings to all. I wish you a Merry Christmas and New Year for those who are participating in Openstreetmap.

This week I had to correct some points in the Metro de Lima (Linea 1), after what I found from maps.me. These improvements are related to the station, the stops and the sections of the Metro.

The details you can find in the history of:

• Relation Linea 1: osm.org/relation/7727216
• Linea 1: Bayóvar → Villa El Salvador: osm.org/relation/7727213
• Linea 1: Villa El Salvador → Bayóvar: osm.org/relation/1408101
• Validation: osmz.ru

www

I spent a couple of weeks in Rosslyn, Virginia, on vacation, and stumbled across a sign identifying the site of the building where the U.S. Defense Department’s Advanced Research Projects Agency (ARPA) invented the network and first attendant protocols, ARPANet, that are today known as the Internet. I photographed the sign and uploaded it to Mapillary, which for some reason has placed it incorrectly (I’m trying to move it to the correct location but Mapillary advises it “may take some time.”)

Can anybody tell me what the binary code on the back of the sign means?

… See full entry

GraphHopper will now route cars over fords recorded in OSM, as confirmed here.

I was aware of this when the change was made because I’ve been keeping track of the GraphHopper driving distance from N’Djamena to Mongo, a route that is something like this:

The sudden rise in distance was caused by a mapper adding a ford between the two places; the drop is when GraphHopper started to route across it.

More details on the recording of routes to follow; for now I just wanted to show this practical usage example.

After showing Missing Maps Mapathon pages and volunteer videos to a 13 years old boy at his home, who was interested in these matters, I forgot to logout from this website then left the place.

I thinks the youngster was impressed and inspired by the website and activities.:o)

If there have been some good works from this Tuesday to Friday, it’s not me (I have just changed my password)…

Was fiddling through the Mapbox GL JS API today, and thought i’d see if I can get the default OSM raster tiles to render on GL. Turned out to be surprisingly easy using this example.

Result:

Demo+code: http://bl.ocks.org/planemad/5670e14b67e3eb82b707ba46c9d3010f

Notes:

• The OSM tiles are raster which are rendered at discrete zoom levels, but the GL interface allows for smooth scrolling. The result might be slightly blurry tiles and may not be as crisp as viewing them in Leaflet.
• The original example was for adding a WMS layer. So any external TMS/WMS layer should work by swapping the tile url in the code. See osm.wiki/Tile_servers for options.
• The color transition of the tiles from b&w was achieved using the raster-saturation property and zoom functions. Not sure if this is practically useful, but definitely avoids needing to render separate b&w tiles.
• An alternative to using Mapbox GL JS for viewing the OSM tiles in GL is to use OpenLayers

deleted by author

It’s 5 in the morning,and I haven’t sleep yet … I mess a lot with Riau administrative boundary … it’s huge nodes after all … more than 10k nodes …

My big plan is – err was – to jump into admin_level 5 directly and add all 12 regencies/cities within Riau province [admin_level 4].

but … it’s not simple as my initial taught, whilst the boundary of riau and neighboring province is created from 3 sources and they all m:

• NE (Natural Earth) 10m –> this is so low res –> some how remind me with ESRI admin00 shp
• Bakosurtanal file (I think), from INIGIS website ( I got files like these prior 2014)
• new, revised 2014 boundaries [known as BPS 2010, because they embed BPS 2010 reference numbering scheme] , taken from PEMILU API, this is so far the newer one and the “most official” one …. aren’t them? lol

And … I’m too afraid messing around with previously old - sacred - relation / boundary created by OSM guru here … :lol:

I know I’m messing around here, and if you mad, you’ll find me in my campus, reviewing my student internship, gosh, there are 15 of them this 8’am, presenting…

[out:xml][timeout:25][bbox:{{bbox}}]; ( node["boundary"="administrative"]; way["boundary"="administrative"]; relation["boundary"="administrative"]; ); (._;>;); out meta;

^ my cheat sheet

I’m starting to reflect on OpenStreetMap over the holiday. The last several months have personally been simultaneously trying and inspiring. Here’s a few thoughts…

We are all the community Do you contribute and participate in OpenStreetMap in any way? Map, organize, code, discuss, etc? Then you are in the OSM community.

We need to move away from talking about the “OSM community” as being either the people we agree with or the people we disagree with. It’s a pattern I see too much. There are plenty of people and groups that are 100% part of the community, but don’t fully realize it.

Community looks different in different places The kind of people, background and settings hosting our community look very different in every city, every country.

This is one of the most amazing things about OpenStreetMap — we’re all working together! University students, open source coders, slum dwellers, professional teams, ambassador(s), geographers. Keeping this in mind is super challenging and necessary for a global project. Trying to understand where others are coming from is something everyone can learn to do, and do better.

We agree far more than we disagree The things we agree on our huge — mapping the entire world openly is still a radical idea.

But the things we argue about might seem like insurmountable gulfs. Yet even on the “polarizing” topics of the past months — organized editing, code of conduct, quality etc — from my seat there’s a huge amount of agreement. Lot of the gulf seems to be about particulars of language and how to get there, rather than essential meanings.

Most of us are quiet The overwhelming vast majority of people on mailing lists and in the OSM community as a whole are not saying anything.

… See full entry

This year has been very special for OSMCha! We have implemented a new interface, a lot of new features and a new backend architecture. We have some new ideas to improve OSMCha in 2018, but we want to start by achieving a better integration with the OpenStreetMap community. So we are starting a mailing list for OSMCha.

As we have more and more people and projects dependent on OSMCha, using the API, deploying their own instances, it is important to have a way to communicate with more agility. A mailing list will be vital to ask general questions, make announcements regarding OSMCha, collaborate on plans and new features, and inform the group of changes.

You can subscribe to the mailing list on https://lists.openstreetmap.org/listinfo/osmcha-dev. Bug reports and wishlist items should continue be reported as Github issues. Please be mindful of the etiquette rules defined on OSM Wiki.

Look forward to talking OSMCha development with you all!

Dear all,

As promised, here are some interesting results of our human-cognitive study after 1 month. The study analyzes how humans are able to describe geographic features in OSM, in particular land-use feature.

Visit the study and participate if you still did not: http://hccvgi.informatik.uni-bremen.de/

Look to some results: http://hccvgi.informatik.uni-bremen.de/reports/index

Enjoy your holidays and Merry Christmas every one.

Dr. Ahmed Loai Ali

Contact:loai@uni-bremen.de

There is some talk about a new scheme for mapping public transport on the German forum.

I’ll try to list some requirements such a scheme should have:

STOPS

• It should be easier to map than the mess v2 has become.
• Simple for simple cases
• Scalable to more complex cases, without the need to convert nodes to ways or relations.
• Details like ref, route_ref, operator, network, zone should only appear on a single object.
• By looking at this object it is immediately clear on which side of the road the stop is located.

ROUTES

• The object that represents a stop for a single direction of travel only appears once in the route relations.
• easy to understand, for anybody who bothers to look inside the relation
• straightforward to process for map rendering
• This means that a scheme with ‘hints’ about the routes, using reference points along the way, is not suitable.
• one route relation per variation of the itinerary

It doesn’t really matter that highway=bus_stop, railway=*, highway/railway=platform are used in combination with public_transport tags. Rendering doesn’t seem to be able to go without the ‘deprecated’ tags. Mapping (using JOSM) is more convenient when using public_transport style tags (roles are set automatically for example).

From the above requirements the only logical solution is to use a node to represent the bus stops. highway=bus_stop / railway=tram_stop bus=yes / tram=yes public_transport=platform

If an actual platform is present where passengers can wait, it can be mapped as a way/area using highway=platform and/or railway=platform. No need for public_transport=platform on these areas, lest someone might say we’re mapping platforms twice. And no need for adding these objects to the route relations. They can be added to stop_area relations. My personal preference would be one such stop_area relation per direction of travel, or per platform in bus stations.

… See full entry

I have been working on the Student City area for about 2 or 3 weeks now, and almost 85% of the buildings have been added, old ones were corrected and their properties were enhanced and/or fixed.

There is still a LOT of work to do, but I really want to finish it all before the start of next year. That won’t be it though, later on it starts the hardest part, ground editing to add shops and maybe take pictures for Mapillary, but that is for another time.

Just in time for “X*mas we’ve started rolling out Vespucci 10 “X”-

I discussed the new C-Mode and configurable validator previously in this diary entry, but there are quite a few other changes:

Version number change

Even though Vespucci has been around for over 8 years, we used version numbers below 1 in a rather nerdy understatement fashion. I’ve been guilty of slightly weird numbering before .

The problem with this is that these days nobody understands if you are not at at least at version 3 after a couple of months and people may actually think something is wrong, so we’ve decided to do a Mozilla and jump to version 10.

While semantic versioning doesn’t really make a lot of sense for applications that don’t expose an API, we will be sticking with a major . minor . patch system for the internal numbering for now.

Support for synonyms in the preset search

The preset search will now use the same list of synonyms that the iD editor does additionally to the internal preset search index. The new functionality is independent of preset translations and uses the same fuzzy matching as the index search. Additional synonyms should be added on transifex to the iD translations.

One of the reasons I based this on existing technology, even though the current system has its warts (we should probably simply gather synonyms completely separately from our translation platform) , is that OSM development already suffers enough from rampant NIH and there is no real added value in asking translators to add synonyms to two different systems.

Support for custom tasks

You can now load (and save) tasks in a simplified Osmose JSON format. The format is not particularly forgiving and must follow the following example:

… See full entry

A few days ago I forgot to spend a minute in an OSM editor. I had almost a month of consecutive edits, level 3 in OSM Streak with almost a hundred points. And then, after a hard day, I forgot about even opening a laptop. Neither an email, nor a telegram notification helped.

The next day I submitted my first changeset in a row. How much did I lose in the game? I had been receiving five points for each changeset (I was too lazy to complete tasks), now I get three, completing the tasks. The fourth level was two months ahead, now… I don’t know, two and a half? 500 points is a long way to go.

… See full entry

I have been working with baseball fields in OSM for my deep learning/OSM project (https://github.com/jremillard/images-to-osm). My partial OSM dataset has around 13,000 baseball fields. I have discovered that around 7% of them are traced just around the infield!

If you map baseball fields, please map the entire field not just the infield.

All of OSM has over 100,000 baseball fields mapped, thats around 7,000 fields are too small. I updated the wiki for sport=baseball to recommend that the entire field be mapped rather than just the infield. In the future, I might make a MapRoulette for this. All of the baseball fields that have an area less than 100x100 ^feet are suspect.

I’ve finally got a reasonable rendering of linear barriers working - like the cattle grid in this picture:

That’s here in OSM and you can see a zoomable map here.

The key to getting it working was to ensure that the width of lines used at high zooms mostly matched the real width of the feature on the map (see here for cattle grids), except for gates and stiles which are designed to stand out slightly. Walls and fences are slightly different, allowing you to tell them apart.

As we’re nearing the launch of the 3d model repository, we now have a test server set up. This means that if you have a tool that could benefit from the use of this repository, you can start live testing it against our API, to support our repository earlier. As this is a closed server meant for testing and only able to handle a small load, I decided against sharing the IP address publicly. If you have an interest in using our API, feel free to send me a private message here to get it!

Additionally, we have decided the 2 licenses we will be allowing users to pick when uploading their models: “Creative Commons CC0 1.0 Universal Public Domain Dedication” and “Creative Commons Attribution 4.0 International“, and are working on acquiring a server for the upcoming launch.

highway tower

With release 4.6 OSM-Carto now much more strongly than before encourages you to map waterbodies and water covered areas of rivers (riverbank polygons) with multipolygons as large as possible. The established and documented practice of dividing riverbank polygons into small, easy-to-handle areas, maybe even exclusively with closed ways instead of more complex multipolygons as it is documented on the wiki, has now been declared undesirable by OSM-Carto.

Some might remember the multipolygon fixing efforts from earlier this year, the numbers are raising again and will be on the same level as before the fixing effort in 1-2 years. It is also well known that large multipolygons break more often and more likely stay broken than smaller ones. Yet incentivising merging of small polygons into larger ones as done by OSM-Carto has no influence on that of course, because … oh look, over there, an ape with three heads…

… See full entry