OpenStreetMap
This is a plan for the addition of building footprint data for Tanga City, Tanzania. The import is currently going through the Import Guidelines steps, and it should be soon an ongoing crowdsourced task
The goal is to import building footprint data developed by Ardhi University (ARU) in Collaboration with Tanzania Communication Regulatory Authority (TCRA) in 2021, using 2019 satellite images.
Read more at : osm.wiki/Tanga_Building_Footprints_Import
Promoting a data-driven decision making culture in Tanga under living lab initiative, we are complementing the global objective of OSM i.e. to create a free editable geographic database of the world by various mapping activities around the region. The initiative uses local member by building capacity on how to use OSM and contributing to it as well as University Students. These mappings have been putting the missing pieces of the community on the map and addressing challenges they face so far. The usage of GIS data as a tool for community as a decision-making data tool can help in timely action and on-time problem-solving.
This is an Initiative for scaling up the OpenStreetMap Project by addition of buildings footprint data for entire region of Tanga,Datasets was developed by Ardhi University Students (ARU) in Collaboration with Tanzania Communication Regulatory Authority (TCRA) in 2021. Furthermore, There are different community mapping activities as micro-works going on in the region, as the mission of enriching and making freely global spatial data as well as capacity building to the local community on how to use free and open source tools in contributing data to OSM.
The current usage of tags in OSM for junctions between motorways is really dangerous in high density areas.
I tried it around Paris with Organic Maps in navigation mode. An oral announce is made few hundred meters that driver should at left or right in few hundred meters, then when the change is no more possible, that the change should be made.
In high density areas, junctions can be on the left or on the right, two or three exits can follow from few tens of meters, making it more confusing, especially if there in not any announce of the name or number of the exit (as in case of Organics Maps), and on often overloaded traffic in these areas.
A good solution could be the announce of the exit direction, number or road name/number to follow, that could be verified on traffic signs, this imply that traffic signs nodes contains these informations. In France, on A6, exit numbers are given (ref field), but not the exit direction/name (name field).
Around Ris-Orangis in about 1000m (~40s at 90km/h) there are lot of changes at left/right between A6a, a6b and A10 The current representation doesn’t display at all the parallel lanes, but only start at the last moment the change can be done, from few tens of meters to several km after the start.
The driving rules, say to go as soon as possible on the exit and THEN to slow down quickly, not to slow down on the main lane, nor to wait for last time to change to exit lane.
Warning: you read this at your own risk and you may collide with a wall of text. I’m sorry, but it didn’t fit in a few words.
I listened with interest to Florian’s speech at SotM 2022 (https://youtu.be/BRv-IFp_zZs), unlike him I do not feel I am a long-time contributor, although I consider myself active, both in terms of OSM editing and my activities in the Polish OpenStreetMap community. I would like to add my voice to the discussion and support Florian’s position a bit.
Let me start with why, in my opinion, the replacement of the current OpenStreetMap operating model, both in terms of the organisation and the database, is necessary. The reasons are the threats and challenges that are becoming more and more apparent and, paradoxically, stem from the growing interest in OpenStreetMap and its development.
By way of introduction, I refer you to Jennings Anderson’s speech at SotM from 2020: https://youtu.be/BI0VrPyAtcQ
and the update he made a year later and published in his diary: osm.org/user/Jennings%20Anderson/diary/396271
I’ll start with the scaremongering - here’s a list of the threats I think we will face in the near future:
Threat One - loss of community control over the project.
Still influenced by my proposal for settlement_type=crannog, I’ve looked at how historic settlements are mapped on OSM. There are three more or less “right” ways to do it (and so many wrong ones…). The three options are
* map as historic= [whatever type of settlement]
* map as historic=archaeological_site + site_type= [whatever type of settlement]
* map as historic=archaeological_site + site_type=settlement + settlement_type= [whatever type of settlement]
The distribution today1 was (in reversed order from above, sorry):
| settlement type/ form | settlement_type=* | site_type=* | historic=* |
| ringfort | 131 | 2 | 0 |
| crannog | 82 | 0 | 2 |
| hut_circle | 24 | 348 | 1 |
| oppidum | 8 | 15 | 3 |
| city | 6 | 612 | 16+(messy mapping) 2 |
| village | 3 | 11 | 58+ (messy mapping3) |
| town | 2 | 0 | 12 (+ 3 “ghost_town”) |
| longphort | 1 | 0 | 0 |
| rundling | 1 | 0 | 0 |
| hut_site | 1 | 0 | 0 |
| hut | 0 | 0 | 12 |
| vicus | 0 | 24 | 0 |
| shieling | 0 | 0 | 20 371 |
| settlement | n/a | 3 788 | ~25 |
In my opinion, historic= [whatever type of settlement] should only be used when the remains are still recognizable as buildings, like a ghost town or some sort of preserved settlement used as a museum (or “visitor experience”, as they’re now known), like some of the Pioneer towns in America.
Everything else I would classify as an historic=archaeological_site, and I personally would like to be able to classify settlements as such and then use sub-classification, if they are known. The high number of site_type=settlement supports that in my opinion.5
Just at home working out how to use my new abn
I wrote a blog post detailing the construction and opening of the new town centre park in Green Square, Sydney. Let me know what you think!
https://jakecoppinger.com/2022/10/the-drying-green-opening-a-new-green-square-park/
Moved to Munich in 2011, and not doing much mapping since… For Belgium I was “in here early” and starting on like a white sheet of paper. All biketours were openstreetmap-wise “new roads” and good for endles mapping entries, in Germany at that time “most seemed done”. Trying to add changes when I see them (new roundabouts, new roads, new maxspeeds) but often they are already taken care off.
–
Following the discussion over my proposal for settlement_type=crannog, I have done some clean-ups in the Historical group. Dear me, it was needed.
Today, I tackled site_type on taginfo which comprised of 38 messy pages. I spent 3.5hours
historic:civilization
site_type to description or name
Changed using aerial imagery; I unfortunately do not live there anymore. Looks really nice. Trees added, suburb transformed.
I’ve spent a few evenings and spare hours this week dusting off and updating osmdiff. If you’re a python developer and you need to interact with replication diffs or augmented diffs, this may just be something of interest to you. osmdiff can retrieve replication diffs as well as augmented diffs from OSM servers, and parse them into native Python Node, Way and Relation objects you can use in your code. This lets you do things like
>>> from osmdiff import OSMChange
>>> o = OSMChange()
>>> o.frequency = "minute" # the default
>>> o.get_state() # retrieve current sequence ID
>>> o.sequence_number
2704451
>>> o.retrieve() # retrieve from API
>>> o
OSMChange (677 created, 204 modified, 14 deleted)
Once you have the data, you can filter and inspect it:
>>> w = [n["new"] for n in a.modify if n["new"].attribs["id"] == "452218081"]
>>> w
[Way 452218081 (10 nodes)]
>>> w[0]
Way 452218081 (10 nodes)
>>> w[0].tags
{'highway': 'residential'}
>>> w[0].attribs
{'id': '452218081', 'version': '2', 'timestamp': '2017-11-10T13:52:01Z', 'changeset': '53667190', 'uid': '2352517', 'user': 'carths81'}
>>> w[0].attribs
{'id': '452218081', 'version': '2', 'timestamp': '2017-11-10T13:52:01Z', 'changeset': '53667190', 'uid': '2352517', 'user': 'carths81'}
>>> w[0].bounds
['12.8932677', '43.3575917', '12.8948117', '43.3585947']
You can also use osmdiffs implementation of Node, Way and Relation objects separately if you need just those, the library is quite small and has few dependencies (just requests and dateutil)
On the list of things in development and slated for the next release are:
* Python __geo_interface__ support so you can easily use them in other Python modules that support them like shapely and geojson
* Retrieving individual OSM features from the OSM API
* Ability to create an AugmentedDiff / OSMChange object with a datetime parameter, which will then calculate the sequence number for you
* More tests, always more tests, and CircleCI integration
Recently I introduced a few “OpenStreetMap Quality Control” categories:
2022 Board elections are coming up for OSMF. You can see what the details will be like on the wiki page from last year. There are three seats up for election, not clear yet who from current Board members will run again.
We need people to run who are focused on specific needs, and ready to put in professional level work on a volunteer basis. In other words, folks who can pick a 1 or 2 things, do good work on them, in service to our community. There are plenty of chunky problems that need ownership.
Me, I’ve been on the OSMF Board longer than anyone. I used to try to cover everything. Now my work in OSMF is very focused on 2 areas – personnel and fundraising. We need to look after our people and make OSMF a good place to work. And we need resources to make our plans happen. It’s a lot, but I’m limiting my time to these.
There’s a lot of noise and energy around any election, and that holds pretty true for OSMF. It’s the one time of year many think about the OSMF at all. But the real work happens in the rest of the year. Very little of the campaign manifestos really matter. Opinions and positions don’t really matter. Through strategic discussion, we largely agree on what needs to get done. Doing the work is what counts, and that’s what we need in Board candidates.
Jumping directly into the OSMF Board with no prior OSMF experience is hard. There’s lots to do on Working Groups and Committees throughout the year. Helps build reputation across our global community, and familiarity with how we function.
That said, whatever your experience, if you are ready to jump and put in the work, I’d love to support you. Reach out and we can talk. I can share my insights on the process and what it takes.
https://sccaz-gis.maps.arcgis.com/home/index.html
Santa Cruz County, AZ government website, contains links to shapefiles for building footprints, addresses, roads, etc. Need to request permission to import? osm.wiki/Import/Guidelines
Finally completed the mapping of the urban environment of Magog (Quebec, Canada). Addition of buildings (15K), major parking lots (700), adjustment of street geometry (3K). Added details on the boardwalk facing the lake.
Began the trace on 11 Oct 2022
After many years, I finally decided to dive back into running a full planet import using the Overpass API.
To keep things budget-friendly, I rented a modest Intel-based server for around 40€/month — nothing fancy, just dual data center SSDs and 64GB of ECC RAM.
What surprised me was the runtime: the initial import using release 0.7.58.5 took a whopping 33.5 hours — at least 10 hours longer than I had anticipated. I managed to shave that down to 26.5 hours by tweaking some settings, like enabling LZ4 compression across the board and increasing the chunk size parameter. It helped, but clearly, there’s still room for optimization.
I continued testing with my own experimental Overpass fork, that includes support for PBF, multithreading, and many other changes under the hood. Initial measurements looked quite promising with 10.5 hours total runtime. After some further analysis and improving some data structures, the import took 7 hours and 23 minutes. Peak memory consumption was still quite ok at 22G. I tried different settings to achieve lower memory consumption, at the cost of longer processing time (e.g. 8 hours and 13G peak memory).
Depending on compression settings, the final planet database was in a range of 230-265GB.
Detailed results are available on this wiki page: osm.wiki/User:Mmd/Planet_import_challenge_22
That’s all for today.
It seems a little
if you ask me.
