This is not too much of a surprise.

Specifications:

In short, the GoPro 11 is getting more pixels per degree of FoV. This is something like 4-5x pixels per degree of FoV. Of specific note, you can theoretically get a full panorama with 3 GoPro Hero 11’s (360/122 == 2.95). If you were to go for a 360 with GoPro Hero 11s, you would need 6 cameras for a “total” 162.78 MP (minus a bit due to overlap). That is almost 10x more pixels per degree as compared to the GoPro Max. Of course, that is also a lot more money ($350 * 6 = $2100 versus $500).

I understand the concern for those who use a language other than English and making a translators job more difficult, but this suffocates the ability to use colloquial terminology particularly here in Australia

There is a (partial) “translation” to Australian English. If you want to improve/fix something, please contribute at https://translations.launchpad.net/josm/trunk/+pots/josm/en_AU/+translate .

I simply do not have the time to attempt to master a very broken u.i.

As a JOSM developer, I would be very interested to know what (specifically) is broken about it. Please keep in mind that JOSM has a small developer team. As in 1 effective full time person, maybe 2 during a “good” month. And most of the effort goes to bug fixes or features that the developers are interested in.

So if you want a ribbon UI, that is not happening (we just don’t have the resources). If you just think that the UI is “ugly”, open JOSM Preferences -> Display -> change Look and Feel to something besides Metal. If you don’t like any of those, the FlatLaf plugin (JOSM Preferences -> Plugins) will add some more. Metal is probably what you are using by default, since the “better looking” ones are more likely to have issues.

Didn’t take me long to work out that josm was more difficult to use than iD

Yep. If only because we don’t have a tutorial to handhold people through the first steps; we do have a wiki walkthrough (the Getting Started section of the start screen has the link). We also tend to encourage hotkeys for common actions instead of constantly poking at the user interface.

browser interface is a pig

Have you tried https://rapideditor.org/edit ?

This is mostly a reply to Koreller:

1. There is a plugin called kendzi3d. If you have issues with that one, try kendzi3d-dev. Neither is perfect, but it should get you going. Neither is something I maintain, although I’ve done a bit of work on the latter.
2. This is something I’d like to do, but it is adequately covered by the Getting Started MOTD section. People just don’t read it.
3. Skipping; iD isn’t something I work on.
4. This is a “hard” ask. There is a lot of functionality in JOSM that could be better exposed, but there isn’t a good way to do so. I’d almost put this behind (2) and try to detect users doing actions that could be done using a tool they haven’t used.
5. Already available. When you have Bing imagery enabled and visible, right-click on an imagery tile -> Show tile info -> Metadata Capture Date. It will be a range. For example, for tile 19/104027/200249, it is 6/24/2020-7/8/2020.
6. Modularization is probably blocked by the Java migration. Which is happening at the end of this year. Also ant -> maven and svn -> git are things we would want to have “done” before we start in on breaking parts of JOSM out into independently usable libraries.

1. Segment Anything in JOSM: As a JOSM dev, I was thinking about doing this, but there are likely to be legal issues with various providers. I would want explicit permissions to run AI extraction on the imagery (if it isn’t PD licensed). If we get permission to run SAM on Bing imagery (or another “global” imagery layer), I think I can justify working on it. I will note that my default will be “no, it is not permitted”. If Microsoft does want to work on this, I don’t mind coordinating with their dev if changes need to be made in JOSM core.
2. With respect to offsets, I would be very careful. Is the newer offsets more accurate to reality?
3. With respect to Bing imagery, I’d like to have two options: most recent (Aerial?) and highest resolution/whatever we get from AerialOSM right now. I don’t think it would be a lot of coding work to support both on the editor side, but we apparently want to use AerialOSM over Aerial in OSM editors now.

Just for the record: https://github.com/simonpoole/pmtiles-reader

I probably should have pinged you when I finished the (initial) bits of the plugin back in August (the PMTiles parsing code was done on 2023-08-10); I specifically wrote it so that other users could just import classes from the org.openstreetmap.josm.plugins.pmtiles.lib package without also needing JOSM in the classpath.

As it is, we now have two different implementations for PMTiles reading in Java. I don’t know which is better, especially since I used Java 17 features in the plugin extensively. Which might have been a deal breaker for you anyway.

All the Places pmtiles also works, https://data.alltheplaces.xyz/runs/2023-09-09-13-32-00/output.pmtiles

Good to know. I do accept PRs for the sources.json file I linked to in my post; just make certain you’ve gone through the following import steps: 1. Tag mapping (so no HIGHWAY=ROAD_CLASS_4) 2. License approval. I’ll take links to an import mailing list discussion and/or a license mailing list discussion. 3. Quality review: I don’t want to have garbage data easily ingested. >50% minimum, but ideally 90% or more. a. On the lower end, I’d strongly prefer to filter based off of street-level imagery availability. I don’t think there is currently a good way to do this globally. I wrote a script awhile back that downloaded Mapillary image tracks on a per-county basis that might help with this for smaller datasets.

@MxxCon: The command line parameter sets the window title bar to a dark color. It could also be -Dapple.awt.application.appearance=system which should follow the system dark/light setting.

A couple of notes:

1. -Dapple.awt.application.appearance=NSAppearanceNameDarkAqua is necessary to make the title bar dark. If you don’t care about that, you can skip the JVM argument and use the standard methods for starting JOSM. Alternatively, if you installed JOSM from the macOS package, you can edit /Applications/JOSM.app/Contents/app/JOSM.cfg (note: if installed per-user, prefix /Applications with ${HOME}) and add java-options=-Dapple.awt.application.appearance=NSAppearanceNameDarkAqua to the [JavaOptions] section. You will have to do that on every update, I believe.
2. java -Dapple.awt.application.appearance=NSAppearanceNameDarkAqua -Xmx7168m -jar /Users/YourUsername/Documents/josm-tested.jar is really java -Dapple.awt.application.appearance=NSAppearanceNameDarkAqua -Xmx7168m -jar $PATH_TO_JOSM_JAR. You can replace /Users/YourUsername with ${HOME}.

Beyond that, I would check and see if it would be possible to automatically add that system property at startup from either the flatlaf plugin or in JOSM core, if there is an easy way to determine that a theme is “dark” without hardcoding class names.

You might be interested in the areaselector plugin.

There are a couple of open bugs on it, notably it may cause JOSM to crash when you are closing JOSM. I’ve got a fix for that, but I’m waiting on one of the JOSM maintainers with GitHub write permissions to apply it.

Note: the %U is documented in the .desktop specification as

%U: A list of URLs. Each URL is passed as a separate argument to the executable program. Local files may either be passed as file: URLs or as file path.

In the script, the $@ is all positional arguments.

Can you please update to r18513 or later, and let me know if it doesn’t work?

This should be fixed in r18512. (The #!/usr/bin/bash has been changed to something a bit more universal). A new stable (r18513) has been released.

One thing I can say is that no one ran into this problem with josm-latest for the past 20 days or so (that is when the offending change was first committed), until after I tagged a new josm-tested version.

I’m sorry about this – it worked fine on my system when I was testing (note: new debian installs have merged /bin into /usr by default – why did debian have to have this half-done half-not-done state for usr merge?).

The reason for the change was to work around an issue where the behavior between /bin/bash and /usr/bin/bash on the shebang line differed, with #!/bin/bash having improper behavior.

As a heads up, the Mapillary images now have a rotating URL. You should not depend upon that URL for embedding images. If you do want to embed an image, you have to use an iframe. With that said, I don’t know if diaries allow iframes. They probably shouldn’t.

I.e.

<iframe 
  src="https://www.mapillary.com/embed?image_key=550092599700936&style=photo" 
  height="480" 
  width="640"  
  frameborder="0">
</iframe>

See https://www.mapillary.com/developer/api-documentation/ for more api documentation.

With respect to

So, it turns out that JOSM can read JSON files. (Yay!) But it is not happy if I try to import a multipart polygon from a JSON file

What version of JOSM are you using? As of JOSM r18441 (a new tested version (r18463) was released on 2022-05-29), it should support random geojson files better. See JOSM #22022 for more information.

Anyway, geojsons with multipart geometries should work better now. If it doesn’t, feel free to open a new ticket.

From a related diary post, https://www.openstreetmap.org/user/R66_Mapper/diary/398993:

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.

How are you getting the addresses?

If they are from an address database, please consider the JOSM MapWithAI plugin (it will automatically merge address points with buildings, you can turn this off if you don’t like it).

If they are from street-level imagery, good for you. :)

You may want to look at mapillary_tools. It is a command line tool to upload images. The README has some examples.

It does look for duplicate images, and doesn’t upload them. You can also normalize the sequence, although I recommend turning on the compass in OpenCamera instead (you will have to recalibrate the compass every so often, it gives a popup).

IIRC, the Mapillary app may not use the actual compass direction, instead using the direction of travel (to be fair, many devices’ compass is… horrible, to say the least). I think you can change that in settings somewhere, but I could be wrong. Its been a little while since I used their application.

So, if you (a) go backward, or (b) are at a traffic light, and the GPS jumps around, you may have pictures pointed in the wrong direction.