OpenStreetMap
There is an excellent blog post from a very curious and original person that made geographic vonoroni maps in R that I’ve adapted to use with OSM attributes and geometery.
Blog post: https://rstudio-pubs-static.s3.amazonaws.com/97256_125b33cf42414eda8797f53ac632628b.html
Code for doing this in OSM with a boundary shapefile.
This post serves as speculation.
Several contributors in OSM make changes in other countries than their own, that makes sense. When it comes to the description of their changesets though, many of them write in neither English nor local language (local for the area they make changes for). The local one is reasonable to not know. But not seeing a changeset for my area/country in either English or local (Greek in this case), makes no sense to me and also makes it difficult sometimes to understand why someone made a specific edit, no matter if it’s right or wrong.
My question though is: in which language should the changeset description be written in? English (as internationally mostly understandable language), the local language (of the area/country the changes are for) or the language of the contributor?
In my opinion, when we contribute somewhere, we want to make the local community understand why we did such changes.
Currently…
The description of the boundary between Electoral Areas C and D given in BC Orders-in-Council 3211/1973 and 2772/1975 is legally vague. The problematic text, as given in BC OIC 2772/1975, is shown in bold in the following excerpt, with context given for clarification. “Township 2” is found in Range 3, Coast District:
“thence northerly along the easterly boundaries of Sections 1 and 12, Township 2, to the point of intersection with the middle line of Bella Coola River;
“thence northwesterly along said middle line to the point of intersection with the northerly boundary of the South Half of Section 12;
“thence westerly along the northerly boundaries of the South Half of Section 12 and the Southeast Quarter of Section 11 to the northwest corner of said Southeast Quarter of Section 11;
“thence west to the point of intersection with the westerly boundary of the watershed of Salloomt River”
The problem is that the actual westerly boundary of the Salloomt River drainage basin lies to the east of Township 2, and therefore the intersection described in the problematic text does not exist.
A data source that differs from the Order-in-Council text has therefore had to be used to draw the boundary between Electoral Areas C and D, and this data source, which interprets the boundary in the area to which the above problematic text pertains, has been properly attributed.
I, Sanish Kumar from Haryana
(Guillaume and Allan wrote this together, and will therefore share the verbal abuse it will generate)
In its first seven months, the ‘new’ (well, no longer all that new) OSM Foundation Board of Directors has made progress on issues facing OSM and the OSM community:
Originally, I wrote this post for my blog: http://plepe.at/398
I love mapping for the OpenStreetMap project, it’s a very pleasing thing to do. I especially like to do it as vacation activity, because then I’m exploring new places anyway, but I also like to do it my home town.
Recently I’m concentrating on mapping artwork and memorials. Even in a well-mapped city like Vienna, Austria, there’s still plenty to do. For example, most social housing building complexes (Vienna is famous for it’s social housing) have some kind of artwork, e.g. some murals or statues in the gardens.
Some examples:
I learned the basics of OpenStreetMap and began doing things that were cool.
The error Al Midhnab, Al Qaşīm
Al Midhnab, Saudi Arabia
the correct (Al Mithnab)
Wrong with the translation into Arabic الميدهناب the correct المذنب
Please correct the error and translation
I’ve done a good amount of work to add basic geometry to Anchorage in the past. Now, I would like to store more data inside the polygons for buildings that have been created.
It is a difficult task to do quality control on the wide number of churches, schools, businesses, etc. in Anchorage because it is just too big. 100’s of buildings in each category where there are also points or multipolgons as well. To accomplish a definitive test of which polygons of a certain type have a data tag, I’ll need to use the overpass API. Fortunately, the work has mostly been done to use it as a tool by relying on R and the library osmdata.
For example, I’ve been able to query all of the amenities with “place_of_worship” to see what tags are available, and map the polygons on top of an osm basemap with the following code.
library(osmdata)
library(leaflet)
library(dplyr)
x <- opq(bbox = c(-150.092146, 61.483194, -148.981596, 60.814537)) %>%
add_osm_feature(key = 'amenity', value = "place_of_worship", value_exact = FALSE) %>%
osmdata_sf()
y <- x$osm_polygons %>% filter(is.na(denomination))
leaflet(y) %>% addTiles() %>% addPolygons(popup = ~y$name)
y %>% as.data.frame() %>% select(name, email, website, phone, denomination)
…This will show me which places of worship still need to have a denomination added. And I reuse this for different tags I want to add.
theguardian:
“Microsoft’s Flight Simulator is a ticket to explore the world again”
( 30 Jul 2020 )
“Most cities are procedurally generated by the AI, based data from OpenStreetMap and an algorithm that provides architectural rulesets for the program to work from.”
https://www.theguardian.com/games/2020/jul/30/microsoft-flight-simulator-game
In the last board meeting the OSMF board has revealed specifics of their plans for paying people for software development work. These plans have apparently been in the making for some time - but so far the board had in public been very quiet about the details - it was first publicly mentioned in the June board meeting but just vaguely and without any specifics. That was the same meeting in which the microgrants selection has been approved.
The details were now made available just minutes before the meeting started (deja vue) - the plans amount to about half the volume of the microgrants program - but there are apparently further plans to also get financially involved in iD development - this has been hinted at in the meeting but details of this have not been revealed.
I want to share a few thoughts on the plans that came to light now - both on the procedural/policy side of them based on the perspective of for many years having critically followed OSMF work and also on the practical side and the likely implications this has on volunteer work and volunteer projects in the OpenStreetMap world based on more than five years of volunteer work on one of OpenStreetMap’s core projects - the OSM-Carto map style - and on more than 10 years experience as an entrepeneur in the cartography and geodata world.
My critical view of the OSMF board moving more and more to making and deliberating decisions outside public scrutiny is well known and obviously applies here as well. But even if i accept this as a given and as how the OSMF works these days no matter how sharply this contrasts with OSM community values there is still significant peculiarity in the whole thing. This centers on how the three projects the board has selected now were chosen. There is no substantial communication about this but from context and from what has been communicated i see mainly the following options:
As part of phase two of the GSoC project, following work has been done.
At the end of phase one, we had a server up and running with nominatim-ui and elasticsearch server. This is from the machine provided to me as part of this project. It currently has the entire planet DB set up. Suggesstions were setup for few smaller DBs, but not for the planet DB as of now. There is constant debugging and changes going on, so the suggestions might not be available at all times. I will post another dairy update once the suggestions are completely available.
The server is hosted at http://95.217.117.45/nominatim/ui. This will be available only during the course of this GSoC project (till 31 August 2020). The suggestions are provided from a hug API call. This can be accessed at http://95.217.117.45:8000/pref?q=. This internally queries elasticsearch on the server and returns the results.
Elasticsearch provides a lot of configurations, which can be tweaked to obtain optimal performance. For our setup, the requirements include: * Require less space. * Fast indexing
The following are few of the options in elasticsearch that were explored during this phase.
These will be tested out with the planed DB indexing, which will be done soon!
The address is being formed in all the languages entered in the Nominatim DB. You can look at all the languages by looking at the tags at http://95.217.117.45:8000/pref. For example:
http://gsoc2020.nominatim.org:8000/pref/?q=bangalore%20north has the result:
"addr": "Bangalore North, Bangalore Urban, Karnataka", "addr:kn": "ಬೆಂಗಳೂರು ಉತ್ತರ, ಬೆಂಗಳೂರು ನಗರ, ಕರ್ನಾಟಕ", "country_code": "in"
Today I learned that there’s a diary function in OSM. Huh. I would hardly refer to my region as “undermapped”, given that streets and addresses are all where they should be, but the wiki says that diary entries help in such regions, and my changes seem to be the most common ‘round these parts.
Since I’m new to this, I’ll explain my rationale for some changes so that the poor innocents that come after me have a reason behind the madness.
Several of the places I’ve been making changes to are just random additions to existing things, such as adding pavement types to roads and footpaths, adding the number of levels and roof types to buildings, and other small stuff like that. That all started months ago when I first learned about the Street Complete app. I liked adding detail to my neighborhood, but I wondered why my options for making changes were so limited.
Months pass, and one of the achievements in Street Complete pointed me towards a browser-based editor that I could use to make changes when I wasn’t walking around. One glance at my changesets as of a few weeks ago shows how well I took to the new editing tools.
Lacking any sort of guidance other than the brief tutorial, I started by adding “house” areas to houses in the area, but didn’t remove the existing address pins for fear of stepping on toes. Aerial images, my frequent walks, and plenty of COVID-19-induced alone time have led me to making more changes in the city, however.
Side note: read the documentation. It’s good for the soul.
More editing has taught me more about how the different parts of the map work together, and seeing those edits being uploaded to the other projects that take advantage of the OSM database is a very nice feeling.
I’ve recently added a new feature to https://map.atownsend.org.uk , prompted by the dreaded lurgi that is affecting everyone at the moment - the ability to show pubs with either outdoor seating or a beer garden.
Outside seating is shown like this:
with a black line at the bottom right of the icon.
Here’s a beer garden:
For example, when I go to tag the surface of a way, “paved” and “unpaved” should not be suggested tags (despite their frequent use), since they’re inherently less informative than more granular tags such as “asphalt,” “concrete,” “gravel,” or “compacted.” I think this is a critical improvement that would greatly improve map quality in the future with at basically no cost. I have no involvement in the development and maintained of iD, but in my opinion, removing poor tag suggestions should be a priority.
Another thought is to help mappers distinguish objects that are similar but not identical, such as bleachers vs. grandstands.
Finally, the wiki should be updated in certain places to better accommodate language translation differences. An example of this is a “give box,” which I’ve only heard referred to as a donation “collection site” or “dropoff location” in the United States.
Recent features and adjustments from version 0.13.0 to 0.15.0:
{osm_tag_key} and {osm_tag_value};Note: if you are using OSM Smart Menu in different browser instances right now, you might lose some configuration data. The configuration from one of the browser instances can be overwritten by the other during an automatic migration after version 0.15.0. This will be transparent for most users and should not happen again.
I’ve recently decided to survey the payphone/phone boxes/amenity=telephone in OSM. To my surprise, they don’t exist any more, well 12 out of the 17 surveyed don’t.
It seems BT is in wave of removing them, publicly they are just “restructuring to save costs”, but in reality it seems they are just removing all phone boxes.
They don’t publish locations of payphones but if you contact them they have to give you a list of any in consultation to be removed, or any recent consultations. They’ll give you a PDF with a postcode and a vague-ish location description. You’ll then need to go out and survey them, if they’re gone, delete them, if they still exist add some metadata tags, ensure its operator tag is correct, add it’s incoming phone number.
I’m going to try and survey the 65 remaining payphones in OSM in my county, based on my last survey, it might only be 20 that actually exist! (75%)
StreetComplete may be helping in this area soon, Tobias Zwick is working on map maintenance through the app so I’ll defiantly be recommending this and bus stops to the list of verification quests.
Hi there-
On the map I’m noticing that the Broad Channel neighborhood is not included within the Queens administrative boundary (interestingly enough, it is labeled as part of Queens within its own description). My Open Map editing skills are not strong enough to edit the Queens Administrative Boundary to include Broad Channel. could someone show me how to do it?
I’m new could use help figuring this out please
