Frustratingly, it wouldn’t let me start a new line rather than adding to an old one as I started adding the trail at the end of the stub of road at the Rio Lado trailhead.

If you hold down alt, JOSM will start a new line. Many of the built-in actions are modified by ctrl, shift, and alt, or some combination thereof.

Fair enough. For the link from JOSM, it should have prefilled most of those fields based off of the currently running system, and gone directly to the download area.

I tried to make it as painless as possible. Obviously I failed. :(

[…]JOSM will soon stop working[…]

Whoa. Scary.

soon stop working is kind of open to interpretation. In this context, it means that future josm-tested.jar downloads might not work with Java 8, not that the current jar file will stop working.

I’m hoping that we’ll be able to move off of Java 8 by end of year, but that kind of depends upon how many of our users move to Java 11 or later.

But I got redirected to definitely-not-Java website.

I tried to make it as painless as possible – I know most people are used to the java.com being the “official” Java distributor, but for Java 11+, it no longer is one. So we have to send users to one of several different Java distributors. We wanted users to have JavaFX (since it is required for some plugins), which decreased the options available. Essentially Bellsoft’s Liberica distribution or Azul’s Zulu distribution. With OpenWebStart, we are preferring the Zulu distribution, so I made the decision to link to Azul’s Zulu page. We are also building our installers using Azul’s distribution.

Well, actually I already know the context behind all of this. Due to recent Java’s license change, JOSM might be incompatible to the official Java release. That’s why JOSM redirected me to Azul Open JDK instead of the official Java site.

It is more a case that java.com doesn’t provide Java Runtime Environment installers for Java 11 or later, and we want to move to Java 11 or later. So we can’t link to java.com.

Okay, now I downloaded Azul Open JDK. Extracted it. But unfortunately, there is no installer at all. Uargh. Another headache.

Stupid question: Why didn’t you use the MSI installer (I’m assuming you are running x64)? It should have appeared as an option (albeit the second option).

Looking at the NAD, it looks like that section of Washington is In Queue (as of August 2022), so it is likely license compatible (the NAD is public domain data).

With that said, can you please verify that the data is license compatible with OpenStreetMap (i.e., is it in the public domain and/or you have appropriate permissions) prior to adding data?

Alternatively, you can wait for the next NAD update, at which point the data should start appearing in RapiD and the JOSM MapWithAI plugin. If you use the JOSM MapWithAI plugin, addresses (by default) are automatically added to building outlines unless another address already exists inside the building outline.

Please note that we have made JOSM available through the Microsoft Store. This also provides auto updates, but on a slightly delayed schedule (1 day or so).

https://apps.microsoft.com/store/detail/josm/XPFCG1GV0WWGZX (for verification that this is the correct link, go to https://josm.openstreetmap.de/ ).

https://wiki.openstreetmap.org/wiki/Tag:service=driveway2 recently passed 10k usages, which means JOSM has to look at it.

Considering almost all usage is from a single user (see https://josm.openstreetmap.de/ticket/21396#comment:44 ), and how it is extraordinarily similar to https://wiki.openstreetmap.org/wiki/Tag:service=driveway from every one else’s perspective, I am leaning towards marking driveway2 as a misspelling of driveway, as most users who do type in driveway2 are likely to have done so by accident.

@JaLooooNz: I kind of get why people don’t like https://wiki.openstreetmap.org/wiki/Tag:service=driveway on access roads for parking lots, drive throughs, and so on, but you really should have used something that was distinct from driveway. For example, since it seems that the sticking point was that some people wanted to make certain all https://wiki.openstreetmap.org/wiki/Tag:highway=service ways had https://wiki.openstreetmap.org/wiki/Key:service tags and other people did not want https://wiki.openstreetmap.org/wiki/Tag:service=driveway on access ways to parking lots, maybe something like https://wiki.openstreetmap.org/wiki/Tag:service=access should have been used instead of https://wiki.openstreetmap.org/wiki/Tag:service=driveway2.

In the future, can you please go through the tagging list and/or wiki proposal process? Or at least don’t use a tag that can be very easily mistaken as a misspelling for another?

The zip file contains a .geojsonl file (notice the ‘l’ at the end of the filename). This file type cannot be directly imported into JOSM. In addition, files on the order of gigabytes will clog up JOSM too much to be usable.

That is roughly correct. JOSM reads delimited geojson files that follow the RFC 8142 proposed standard, which depends upon the RS (0x1e) record separator character. Assuming you have jq installed, you can run the following one-liner to convert the geojsonl file to something JOSM will open:

$ cat 'United Kingdom.geojsonl' | sed -e 's/^{/'$(printf "\x1e")'{/' | jq -c --seq . > 'United Kingdom.geojson'

You’ll still have to deal with the data slowing down JOSM (it tries to draw everything), but that can be fixed by zooming in once everything loads, assuming you have allocated enough memory to JOSM.

With a 6.0 GB file, you are going to want to allocate more memory to JOSM (see JOSM OutOfMemory), since the default memory given for JOSM is typically 4 GB or less.

Yes, we don’t have to keep the whole file in memory, but we do have to keep the data from the whole file in memory, since we aren’t just processing it and forgetting about it (which is where the line-delimited geojson format makes a difference).

1. Set up flatpak (see https://flatpak.org/setup/Chrome%20OS )
2. Install JOSM from the flathub repository (see https://flathub.org/apps/details/org.openstreetmap.josm )

I am hoping that this becomes easier in the future (see https://chromeos.dev/en/posts/bringing-steam-to-chromeos ), but time will tell.

Quick comment for people reading this post and wanting to use kendzi3d:

At the time of writing, the Kendzi3d plugin works on Java 8 only (and not at all on Mac). There is a version which works on Java 9+ (and Mac) called kendzi3d-dev. If you install kendzi3d-dev, please be aware that it is intended to be short term workaround (I was hoping to get it merged into kendzi3d itself last week, but there are a few niggling issues). When kendzi3d-dev is removed from the JOSM plugin list, you will not be automatically migrated to kendzi3d. I may be able to add an informational dialog indicating that users should switch to kendzi3d, but you should not count on it.

Did you file a bug report at https://josm.openstreetmap.de/newticket ?

Please keep in mind that developers cannot fix items that they do not know about, and filing good bug reports is a way to (a) tell the developer about the problem and (b) how to reproduce it.

My best guess: something deleted a new node that was in way/741879858 without updating the way. Which shouldn’t happen.

Anyway, notes on how to fix the problem:

1. Unzip the JOSM session file (.joz) into an empty directory.
2. Open the layers/{some number}/{some name}.osm file in a text editor (e.g. Notepad). The {some number} placeholder is some number, and {some name} should be the data layer name.
3. Search for -104469 and delete all references to it. Example (simplified for readability):

<way id="741879858" version="1">
    <nd ref="-104469"/>
</way>

In this case, only delete the <nd ref="-104469"/> text.

1. Save the file
2. At this point, you can either create a new zip file or just open the edited OSM file in JOSM.

No problem.

We just released a new version of the JNA plugin, which should fix the issue. So people just need to update plugins prior to following your instructions.

Just a heads up, if you install any plugin which depends directly or indirectly on the JNA plugin, JOSM may freeze on startup. If this happens, you may need to either (a) delete the jna.jar file in ~/Library/JOSM/plugins and/or (b) edit the preferences.xml file in ~/Library/Preferences/JOSM and remove <entry https://wiki.openstreetmap.org/wiki/Tag:value='jna'/> in the <list https://wiki.openstreetmap.org/wiki/Tag:key='plugins'> xml block. You will get an error about the plugin jna missing. So you may want to remove all of the affected plugins from that same list. See the list at the bottom of this post.

See https://josm.openstreetmap.de/ticket/21620 . Hopefully, an updated JNA plugin will be released in the next few days. Until then, if you do need any plugin which depends upon the JNA plugin, use any of the packages that are going to run using x64 emulation modes. This may affect other plugins that bundle JNA themselves, but they are going to have to update JNA individually.

This may affect the following plugins (each level indicates that the plugin(s) depend upon the upper level, and I’ve tried to indicate where each may cause a freeze):

• apache-http
  • MicrosoftStreetside (may cause a freeze on downloading the Microsoft Streetside layer or attempting to view an image)
  • Mapillary (may cause a freeze on downloading the Mapillary layer and attempting to view an image)
  • TombPlugin
  • mapwithai (may cause the startup freeze – it tries to update data sources in the background on startup)
  • osmwiki-dataitem (may cause a freeze when it attempts to get data about the current key/tag, or uploading new key/tag data to OSM Data Items)
• native_password_manager

P.S. JOSM recommends Azul or Bell Software Java distributions, preferably with OpenJFX (JavaFX) included. See https://josm.openstreetmap.de/browser/josm/trunk/README .

Spaces in the file path shouldn’t break it, but it wasn’t something I tested when I was coding the MVT support.

As you noted, JOSM does internally convert the Mapbox Vector Tile Style into a mapcss file. I don’t remember coding anything specifically to clear the mapcss on changes from the MVT style, but I also wasn’t coding for that specific use case – I only added that ability to simplify testing while coding.

There is a lot that can be done to style MVT layers, but I didn’t implement everything – that would have been (a) a big lift and (b) would have required more from the mapcss implementation. In the interest of getting support into JOSM, I only added mappings for stuff that mapcss supported.

See https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/imagery/vectortile/mapbox/style for the source code. Layers.java is probably the file you would be most interested in.

It is great to see people start using the functionality. :)

Source: I was the person who had to implement MVT support.

I don’t think we made it explicitly clear in the documentation, but you can add any server that provides OSM XML in preferences (or via remote control, for tasking managers). It just has to take a bbox in the same format as the main OSM API (left,bottom,right,top). So, if you have a county/state/country that has released address data into the public domain (or is allowing OSM to use it), you can spin up an OSM-like server and serve the data that way for importers.