What’s one feature you’d love to see or improved in the OpenStreetMap?
Database redesign to get sql dump along with xml/pbf.
Define “OpenStreetMap” here.
The osm.org website? The database? The default map (i.e. Carto)?
(interpreting the question as about "the https://www.openstreetmap.org website)
The ability to easily use your own maps in place of the six layers there, so that in place of
we can instead get e.g.
(or whatever else takes your fancy)
Frequency of imagery updates, & clearer imagery!
Recently, I discover Cursor IDE with AI integrated in many parts. One thing that I liked from that is that it can create automatic commit messages.
I was thinking to something similar in OSM changesets, to prevent these dumb messages:
- .
-
- update
Instead, OSM API or the editors (id, JOSM) could generate the changeset message from AI, that provides something useful based on the objects modified.
IMHO the most useful comments are those that give context or motivation, i.e. why something was modified (e.g. “the cafe is gone and there is a hairdresser now”, “the owner has set up a gate and the way is not accessible any more”, “the path was washed away in the last storm”, …) rather than a list of things that were done (“added 3 traffic signals and a hairdresser, removed a cafe”), and I would suspect the AI to give the latter and not the former, because I doesn’t know the reason why you did something. We do not need longer and more exhaustive comments, we need those that let us understand why it was done, what were the reasons.
I am saying to use AI for those cases where there are dumb messages. Not for every changeset comment.
I would dream that, when asked for pedestrian travel, OSM not only provides the shortest trip but also the amount of up-and-down (altimetry) walk, and the ability to modify the track by clicking on a given point in the path and dragging it somewhere else, while of course keeping the memory of operations (for undos) and updating in real time the data related to travel (duration, length, up-and-downs). An added value would be for the path being modified to catch the closest path element visible at the display scale.
To clarify little bit the scope, earlier I wrote OpenStreetMap ain't Google Maps | Andrii Holovin – Blog to differentiate what is OSM and what isn’t. I hope it will help anyone to clear express their ideas.
One more feature to enhance is using buffers to describe the affected area instead of bounding boxes (envelopes) in changesets. This approach eliminates the disadvantages of “huge area” changesets that cover the entire map when one feature is in New Zealand and another in Anchorage, Alaska. Instead, there would be only two buffers around the changes, not the entire world. Consequently, this would significantly improve the History tab.
UPD. This idea was already mentioned in issue #756 weeklyOSM. https://weeklyosm.eu/?s=improving+the+process+of+forming+changesets.
I think we need to go into a little more detail here. Currently, the ERD of the database looks like this (see diagram), meaning that all project components are stored in a single DB.
That is, the project data itself (nodes, ways, relations, changesets), notes, user credentials, diary posts, GPS tracks, information about users’ blocks, administrative resources — all this is a single database. This approach makes it impossible to publicly disclose the SQL dump of the database without exposing sensitive information about the participants of the project.
The way out of this situation is either to use Schemas in PostreSQL for each component of the system, or to divide a single database into separate databases, one for each component, which are interconnected.
Using this approach, you can assign appropriate access permissions to each database component. For the component containing geospatial data, as well as for diary posts, notes, GPS tracks, and so on, you can grant public SQL access without disclosing sensitive user information. This, in turn, allows you to get an SQL dump only of the data collected by project contributors, as well as to run direct SQL queries against the database to get any publicly available project data.
Dividing the database into separate parts will improve the project’s resilience and maintainability. In such a modular structure, issues in one part that may arise during operation, or improvements implemented, will not have a major impact on the other part and the entire system.
I hope that the Engineering and Operational working groups will take note of this proposal and that its implementation will benefit the entire project.
If it’s also regarding Carto,
I’d really like to see highway=busway rendered, and also natural=shrubbery
These are important and well established tags that deserve to show up on the map.
I agree with you that it would make sense for any general purpose map style (such as OSM Carto) to show things that are widely supported like those features, but why the OSM Carto maintainer isn’t going to fo that has been discussed many times elsewhere.
What - and this is a political question, ot a technical one** - do you suggest as the way forward?
** technically the steps required are all solved problems including changing a map style to show busways and shrubberies and adding new tiles layers to osm.org.
If I would have time to invest into this I would try following:
- fork the existing OSM Carto project (create a new style based on it)
- making distinct brand-new style is likely going to face a bigger problem with final step
- preferably find another person/people interested in improving it
- implement some changes, maybe like this busway one
- propose replacing current OSM Carto by new style - though I admit I am not entirely sure should it be directed to OSMF, website maintainers or general OSM Community
- asking gravitystorm to kick out existing maintainer and becoming maintainer of gravitystorm/openstreetmap-carto project is I think a worse idea, in multiple ways
I would give decent chances of success of it replacing current OSM Carto, though it depends on how it would be executed. Also, may be made irrelevant by vector-based map.
There may be a better way to achieve this. But either way you will certainly get some drama and uncertainty about outcome. I would not do this if someone deal poorly with drama and politics, especially if they tend to generate plenty of either.
If someone is interested in this but dislikes uncertainty and politics adopting HOT map style is also possible.
But I suspect that not a lot of people are actually interested in being a maintainer of such style. I used to be one for some time and right now I am not willing to spend my hobby time on that.
what is the benefit here?
@Mateusz_Konieczny
See details here What’s one feature you'd love to see or improved in the OpenStreetMap? - #12 by andygol
this does not seem an obviously good idea
we already have problems with some misbehaved scrappers, this would add extra complexity of rate limiting within core system
However, this is a different kind of issue. If we provide public access to the data, it is possible that the number of cases of improper access to the site will change for the better. I have described the possible benefits for users who behave properly. Perhaps you can suggest ways to deal with those who break the rules.
I wish it weren’t so easy to vandalize the OSM map using sockpuppet accounts. I know it’s probably very hard to prevent technically, but those who try to do things right end up getting tired.