Did you just get a Chromebook, and excited to get mapping with it? You can run JOSM on Chromebook with a little bit of effort. This guide was written for ChromeOS 74.0.3729.159 and up and relies on the Debian Stretch 9 emulator Crostini. As you’re entering these commands, you can copy and paste them from the website to the Debian terminal by using a right click (or Alt + Click if you don’t have an external mouse connected)
Open the Settings app, and search for Linux. Click “Turn On” to enable Linux support. On the popup installer, click Install. Sit back and wait. When the installation is complete, a Debian Linux shell terminal will automatically open.
This command adds the JOSM repository to the sources list.
echo deb https://josm.openstreetmap.de/apt alldist universe | sudo tee -a /etc/apt/sources.list
Download and register the OpenStreetMap public key.
wget -q https://josm.openstreetmap.de/josm-apt.key -O- | sudo apt-key add -
This will query updates to all packages, and install josm afterwards. This will take quite some time. Go grab a coffee.
sudo apt update ; sudo apt install josm
Open up JOSM within the App Folder “Linux Apps” from the launcher. It’s possible that JOSM could have too small a font to read on your screen. The fix is to install Java 11 and use UIScaling to render the applet with a larger font. If you wish to fix this and give JOSM a larger font, follow the next steps:
Debian Stretch doesn’t come with Java JDK 11 by default, but we can enable it by adding the backports software repository.
UIScaling is only compatible with JDK 11, not the default JDK 8. We need to upgrade. Enter this command:
sudo apt install openjdk-11-jdk
We want to make sure JOSM is configuring itself to use JDK 11 instead of 8. Reinstall it.
sudo apt remove josm ; sudo apt install josm
We need to inject the UI Scaling parameters into the launcher tile. The best way to do this is with the command line text editor nano, but you can use whichever editor you are most familiar with.
sudo apt install nano
Once nano is installed, use the command sudo nano /usr/bin/josm
Navigate to line 27, and you should see this option:
JAVA_OPTS=”-Djosm.restart=true -Djava.net.useSystemProxies=true $JAVA_OPTS”
Edit this line to state the following:
JAVA_OPTS=”-Dsun.java2d.uiScale=2.0 -Djosm.restart=true -Djava.net.useSystemProxies=true $JAVA_OPTS”
Our underpaid team of data wranglers have been working diligently over the last six months to develop and bring forward our proposal for importing addresses statewide into Massachusetts. This has been no easy process, and has many specific concerns which we’ve been working hard to address over the last six months of development for this plan. We have come up with a multiple phase-based import approach which we believe mitigates data issues while providing high quality data to be imported, sought feedback from our local community, and have now submitted our request for comments to the national imports@ list for further discussion before starting the import process.
As a background, we discovered MassGIS data on address parcels available through the 911 data within the state. The raw data consists of points which are located on top of the building centroids, as far as the state is concerned where the buildings are. For multiple building properties, the address point is located in the center of that property. This is workable, but means the data has to be filtered between the two import phases to fix the correlation between the two types of nodes.
This marks a significant milestone within our local community’s mapping development. Importing addresses to every building in Massachusetts is no small task, but the effect on data quality and usability of OpenStreetMap will be significant. The wiki link for our import proposal can be found here: https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses
You are invited to provide feedback on our process on imports@. If you’d like to contribute, we need data wranglers and coders. Feel free to reach out on talk-us-massachusetts or #massachusetts on the OSM US Slack.
Over the last couple months I’ve been busy fixing mapping in North Andover, MA, where I currently live. Issues with the mapping here in Massachusetts have largely been because of a lack of addresses, street data, business data, and stagnant notes left on the map for upwards of 4 years or so.
I’ve been very active with a couple projects as of late:
This project is progressively going through all parcels within the town and manually adding each address to the building, plus adding driveways, and assigning building=garage or shed as necessary. Plus, drawing in sidewalks as separate ways and correcting intersections and turn restrictions as necessary. It’s a slow process, because there’s so much to verify and add, and I’m doing this process largely on a block-by-block process, alone. This has gotten massively easier lately, however, as I’ve learned how to use JOSM to some extent, and discussion started about a Massachusetts wide address import, of which I provided details on how to do such an import using JOSM and the Conflation plugin. (Details of the current import effort are documented here: https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses) Let’s delve deeper into this…
The Massachusetts Basic Address Points is a database divided by town with POI / point data encoded at the center of building polygons for addresses, however the data for streetnames and housenumbers have tags that need renaming, and all the streetnames are in upper case. We had lots of talk on the talk-us-massachusetts list and discovered several issues:
1. Is the title() function appropriate considering the possibilities for false positives, and how many such positives would there be (McCoy Street, YMCA Way).
2. How would you handle data conflicts with multiple addresses to the same building.
3. How would you split up the data import so that it doesn’t cause havoc on the server?
My opinion on the title() function was that the number of double capital items that would be made in error would be small enough to still warrant importing all address data, reliant on persons to manually or semi-manually edit such features at a later date. I believe we came to an agreeing consensus, but discussion is still taking place on this.
I suggested that data conflicts could be manually reviewed. If you have 36 Howe Street, and the import wants to put in 38 Howe Street next to it, you could pull up the MassGIS parcel map, check which neighboring parcels are officially using which addresses, and in this case, merge the two into addr:housenumber=36;38. Note, I wouldn’t use the hyphen symbol, as it has the connotation that every number between the two are in the same building, e.g. 36, 37, and 38 Howe Street, which may or may not be the case. Discretely listing each one as it’s own number separated by a semicolon is much cleaner.
While the community continues to stir on the subject of how to execute a massive import of the data, I realized that I could use this address data to simplify my own small scale edits. By loading the address import database for my town in with my edits, I can conflate the import data, do a manual verify for each address using the L3 Parcel Map, move buildings, draw addresses, and complete it all in one fell swoop. I thoroughly reviewed the OSM Wiki on whether doing small scale imports with manual verification are an issue, and apparently it doesn’t qualify as an automated edit, and not necessary of a full import documentation, since it’s all verified personally for each and every edit being made. It’s still a slow process, but verifying matching data is a lot faster than clicking and entering numbers ad nauseum. It’s progress.
As such, the North Andover address and general fix-up project is about 20% complete, with all addresses west of MA Route 125 being completed and verified. I really wish I knew how to implement a tasking engine to make this easier…
I’ve also being doing detail/micromapping of very specific locations within the town. Specifically, Merrimack College, large shopping areas, or public schoolgrounds. I read through the information contained on the wiki, and basically came to the conclusion that micromapping is fine, but if done in specific circumstances that could warrant it. I feel as if it’s warranted for locations where the land features are managed, such as planted trees, parking lots, and public areas. It helps to create detailed views of these public areas so people know exactly what it will be like there.
I’ve been drawing grass, adding trees, walkways, and parking lots to make such locations as detailed as possible.
I’ve been listening to the SOTM talks while at work, and discovered one talk about turn based and directional assistance mapping within OSM. Apparently some of the modern tools being developed are using front facing camera data to assign turn lanes, and using these tools you can easily add such data into OSM. I plan on exploring this some more, but for those curious, you can see the talk here: https://www.youtube.com/watch?v=MEml0vO3qvM
As always, I’m learning new things about OpenStreetMap every day, and every little bit of mapping I do helps to learn new tips and tricks about mapping more effectively and in a way to make a better map for others. JOSM is great for power mapping and toolset use, but iD still provides a dirt-easy way to contribute.
I’m a firm believer that maps are more useful with the more data on them as you can put in. Seems logical, right? When I was looking at OSM, and OsmAnd, it appears that the local functionality of the system as far as address and route guidance is completely useless as of right now, primarily because nothing has addresses entered. It’s great that so much roadway and outlines of buildings have been added, but the map is pretty much useless for the end user who just wants to get from point A to point B.
For this reason, I did some digging and was able to find North Andover’s zoning map, which includes property address numbers! (https://northandoverma.mapgeo.io)
I’ve set out to iterate through all of the addresses I can systematically over time and transfer them all into OSM. I’m sure there’s easier ways… some suggested JOSM with a MassGIS address layer, but JOSM is fairly difficult software to use and I don’t quite understand it yet. So far, I’ve been using iD editor, but that has challenges in that anything over about 100 concurrent edits in the current changeset starts really bogging down the web browser, so I have to save often.
The mission: to update all addresses systematically from west to east, to draw in driveways, and to fix misaligned buildings as I go through.
This is going to take some time.