Hello! Today, I want to share a handy script that can enhance your experience with JOSM on MacOS by enabling a dark mode theme. Dark mode not only looks sleek but can also reduce eye strain, especially during late-night mapping sessions.

Note: This script is specifically for MacOS users.

Step 1: Download JOSM

If you haven’t already, download the latest version of josm-tested.jar here. Save it to a location on your Mac.

Step 2: Install the FlatLaf Plugin

FlatLaf is a fantastic plugin that allows you to apply dark themes to Java applications. After installing the plugin and restarting, go to the menu and select the dark theme: JOSM → Settings → Display → Look and Feel → FlatLaf Darcula

Step 3: Create and Run the Script

Now, let’s create a script that will launch JOSM with a dark theme. Open your favorite text editor and paste the following code:

shell #!/bin/zsh

java -Dapple.awt.application.appearance=NSAppearanceNameDarkAqua -Xmx7168m -jar /Users/YourUsername/Documents/josm-tested.jar

Make sure to replace YourUsername with your actual MacOS username. This script does the following:

• #!/bin/zsh: Informs your system to use the Zsh shell to execute the script.
• java -Dapple.awt.application.appearance=NSAppearanceNameDarkAqua -Xmx7168m -jar /Users/YourUsername/Documents/josm-tested.jar: Launches the Java runtime with dark mode enabled, allocates 7168MB (or 7GB) of RAM to JOSM (you can adjust this value), and specifies the path to your JOSM JAR file.

Step 4: Save and Make the Script Executable

Save this script with a .command extension, for example, josm-dark-mode.command. To make it executable, open your terminal, navigate to the directory where you saved the script, and run the following command:

shell chmod +x josm-dark-mode.command

Step 5: Execute the Script

Now, you can simply double-click josm-dark-mode.command, and JOSM will launch with a beautiful dark theme, thanks to the FlatLaf plugin and the MacOS appearance setting.

Enjoy your enhanced JOSM mapping experience with the dark mode theme. Happy mapping, and may your edits be as precise as ever!

I was watching the movie Mission Impossible: Fallout and noticed that the arms dealers used a map based on OpenStreetMap to plan their operation (41:50). I could be wrong, but it seems to be osm-carto style: This place is not far from the Pont de Bercy:

I want to share my experience using the CAD Tools plugin for drawing ways with smooth bends in JOSM. I want to emphasize that I don’t claim that this mapping method is the right or useful one. Most mappers tend to show object contours with as few points as possible. I see the advantages of this approach as it makes data easier to edit, especially in mobile and browser-based OpenStreetMap editors.

On the other hand, smooth line bends work well for the shape of most objects we map. Roads, being one of the main features on maps, are always represented by smooth lines best described by Bézier curves. Coastal lines of various water bodies almost always have smooth bends.

My considerations are as follows: the closer the data represents the true shape of an object, the more accurate the data is. Ultimately, my main motivation is that smooth lines are very aesthetically pleasing.

In the video below, I draw vegetation and water bodies using the CAD Tools plug-in for JOSM and the way simplification feature. My main recommendation for those who want to do the same is to avoid getting too carried away with smoothness. Don’t use too many points; find a balance between the number of points and the shape of the line you are drawing. Otherwise, someone from the community will simplify your ways and they will be right!

Link to the video on YouTube

There is one caveat regarding CAD Tools—use the “Cut corners” feature only on newly created closed ways. There have been cases where this feature corrupted existing ways in the database, leaving only points. Be cautious!

OpenStreetMap (OSM) is an invaluable resource for geospatial data, providing free and open access to information about our planet. One interesting aspect of OSM is its ability to track the history of changes made to objects in its database. As someone curious about geospatial data, I’ve been exploring ways to visualize this data in a more intuitive manner. Recently, I decided to experiment with GPT-4, a state-of-the-art language model by OpenAI, to see if we could come up with a fresh approach to visualizing OSM data history. In this blog post, I’ll share my initial attempts, examples of the traditional OSM Deep History table, and the new visualization I created with GPT-4’s assistance.

Traditional OSM Deep History Table

The standard OSM Deep History page presents data history in a tabular format. While it’s a helpful tool for understanding how objects in the database have evolved, the table format can make it difficult to quickly grasp changes and trends in the data. The table includes a row for each version of the object, with columns for different attributes. As a result, finding meaningful insights can be challenging.

Figure 1: The traditional OSM Deep History table displaying object history in a linear format.

Experimenting with GPT-4

To create a more visually appealing and intuitive representation of data history, I decided to experiment with GPT-4. Together, we developed a new approach to visualizing OSM data history using an enhanced table format ಠ_ಠ in the browser. This new visualization prioritizes the most recent changes, sorts the columns based on the order in which the keys first appeared, and clearly highlights additions, deletions, and modifications to the data.

Figure 2: The experimental visualization created with GPT-4 assistance, organizing the data more effectively and emphasizing important changes.

Illustration Comparison

The traditional OSM Deep History table displays the data linearly, making it difficult to quickly identify changes and trends. In contrast, the experimental visualization enhances the presentation by organizing the data more effectively and emphasizing the most important changes. This helps users more easily understand the evolution of the object and gain deeper insights into its history.

Conclusion

My initial experiments with GPT-4 to visualize OSM data history have been an interesting learning experience. These are just my first attempts at data visualization. If you’ve come across any such examples or have ideas for other applications, please feel free to share them in the comments below.

1. Install Java Development Kit for ARM 64 processors. JOSM developers now recommend Azul or Bellsoft Liberica JDK’s. At the moment, I’m using the Azul build: https://www.azul.com/downloads/?package=jdk#download-openjdk

2. Download josm-tested.jar https://josm.openstreetmap.de/josm-tested.jar

3. Drag and drop josm-tested.jar into the Dock

4. Run JOSM!

PS: Updated recommendations for JDK

UPD April 20, 2024: The instructions are effective; however, the JOSM development team now produces a build that supports both Intel and Apple Silicon processors. Currently, I download and install JOSM using Homebrew.

The Ukrainian community is concerned about the possible negative impact on the project as a whole, the emergence of lawsuits from users of data and the subsequent decline of the project, and therefore restores the borders of Ukraine to the internationally recognized status. The recent decision of DWG ( https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/DWG_2018-11-14_Crimea ) neglects the wide recognition of Crimea as an integral part of Ukraine expressed by numerous governments and international organizations (in particular, UN General Assembly Resolution 68/262 http://www.un.org/en/ga/68/resolutions.shtml / https://undocs.org/en/A/RES/68/262 ). DWG actions directed to cut off Crimea from the borders of Ukraine are considered to be inadequate to the interests of the project and are not recognized by law. Any blockages (bans) aimed against members who restored the border of Ukraine to the widely internationally recognized status will be seen as unjustified pressure on the entire community and usurpation of power in the OSM.

P.S.

“changing names or country information would require consensus from both the Ukrainian and Russian communities. It is unlikely that any such edit proposals will be able to achieve this.” (с) DWG //

Moreover, according to clause 4, a consensus should be reached between the Ukrainian and Russian communities on changing information about countries. There is no consensus - there is no reason to separate the Crimea from Ukraine.

CrimeaІsUkraine #DWG #CrimeaMap #КримЦеУкраїна #ИхТамНет

https://www.openstreetmap.org/relation/60199

https://www.openstreetmap.org/user/velmyshanovnyi - https://www.openstreetmap.org/user_blocks/2360 ;

https://www.openstreetmap.org/user/velmyshanovnyi - https://www.openstreetmap.org/user_blocks/2359 ;

https://www.openstreetmap.org/user/andergrin - https://www.openstreetmap.org/user_blocks/2358 ;

https://www.openstreetmap.org/user/Дівчина_з_Коломиї - https://www.openstreetmap.org/user_blocks/2357 ;

https://www.openstreetmap.org/user/паляниця - https://www.openstreetmap.org/user_blocks/2356 ;

https://www.openstreetmap.org/user/frankoivan - https://www.openstreetmap.org/user_blocks/2355 ;

https://www.openstreetmap.org/user/pumpkinpie226 - https://www.openstreetmap.org/user_blocks/2354 ;

https://www.openstreetmap.org/user/Хтосьіншийдятел - https://www.openstreetmap.org/user_blocks/2353 ;

https://www.openstreetmap.org/user/ue0 - https://www.openstreetmap.org/user_blocks/2350 ;

https://www.openstreetmap.org/user/andergrin - https://www.openstreetmap.org/user_blocks/2348 ;

https://www.openstreetmap.org/user/KKS - https://www.openstreetmap.org/user_blocks/2347 ;

…and other

-