Support for Node Coordinates in CSV output

[julcnx]

Hi there — first of all, great tool! I use it a lot for historical OSM data analysis and it's been incredibly helpful.

Would it be possible to include node latitude and longitude coordinates in the CSV output?

Currently, it looks like this information isn't exported—at least not via the key column—and having it would be extremely useful for tracking how geometries evolve over time.

I'm working on a data quality project, specifically reviewing all path geometries added by particular contributors within a specific area. I’m importing the CSV output into a PostgreSQL database, with the goal of eventually generating GPX files based on the historical data. Unfortunately, the lack of lat/lon coordinates for nodes makes this workflow more difficult.

Since the coordinates are already present in the .osh.pbf files, it would be great to have an optional --coords (-c) parameter that could include this data in the key, old_value, or new_value columns when applicable.

[amandasaurus]

I'm glad to hear that you're using this tool. I'd love to link to your project(s) in the read me.

I'd happily accept a PR which adds this sort of feature. I can see the benefits. It's relatively easy to do for nodes. You can include old and new coordinates. But I don't know what to do for ways or relations. The first version could be to just not include any coords for those types.

Maybe later, one could include "coords of first node in this way" or something? For 99% of the ways, it will give you "accurate to within a few meters". Which is probably still really good if you only need location accuracy to within ±50 m. I reckon you can make statistics on city level tagging changes , which is still cool. One would have to find a good UI name or column name for that.

[julcnx]

I'm glad to hear that you're using this tool. I'd love to link to your project(s) in the read me.

Thanks! Just personal research for now—nothing public yet, but I’ll keep it in mind for later ;)

I'd happily accept a PR which adds this sort of feature. I can see the benefits. It's relatively easy to do for nodes.

I'll give it a try—I found that curr.lat_lon() should provide the values I need.

But I don't know what to do for ways or relations. The first version could be to just not include any coords for those types.

Maybe later, one could include "coords of first node in this way" or something?

For ways or relations, it might make sense to track either the start and end points or just use the bounding box as a key—I'm not sure yet. But to begin with, I’d focus on the node coordinates. A single key like coords might be sufficient; I don’t see a strong need to track latitude and longitude changes separately.

[amandasaurus]

On So, 04 Mai 2025 16:43 +02:00, julcnx ***@***.***> wrote: I'll give it a try—I found that `curr.lat_lon()` should provide the values I need.

Cool! 🙂

For ways or relations, it might make sense to track either the start and end points or just use the bounding box as a key—I'm not sure yet.

Annoyingly, ways can change geometry without the way id changing. So there's no very easy way to calculate it. But it could be “good enough”

But to begin with, I’d focus on the node coordinates. A single key like `coords` might be sufficient; I don’t see a strong need to track latitude and longitude changes separately.

A part of me wants each float to be a different column (`old_lat,old_lng,new_lat,new_lng`). 🤣 But I don't mind. I wonder: Is it worth having a column with a distance between old and new, and/or a boolean column saying if the node moved? Would it be useful to track “this is a tag change where the location didn't change”?

…

-- Amanda