I meant the default OSM layer.
“mapnik” name is used all over the code so I just sticked to it. 
By base layers I mean all layers from the sidebar panel:
And this is the current limitation view (when switching to CyclOSM, for example):
I asked that question the way I did to get that (telling) answer. “Mapnik” (as an assumption as Standard) shows you are using an older view of things as we do them now. Sure, there’s going to be some of that, I’m certain you know this.
It’s just because openstreetmap-website has such naming convention and I simply got used to it 
. I think I will just rename it to “standard” for the sake of it. Thanks for that bug request - you are one of the first!
And that’s because Carto is using Mapnik library, which is used in other maps aswell. Hence the reference of Mapnik in the code.
1 Like
I know that GitHub is widely used (I view things there) but it has remained proprietary to Microsoft for 7+ years and one can’t follow your link without a GitHub login. See, it’s easy to get “a particular mindset” (or perspective, or “locked into” naming conventions…) while others don’t have something similar going on in our minds. (Many of us stay current to the extent we can though in OSM, even for the savvy among us, that’s hard to do, though there are efforts like @wambacher who keeps track of versions of things). Though I myself do try to keep up with what you say and do. OSM is a large system of moving parts. Maybe enormous is a better word.
When this is true (and especially as serious structural changes are being discussed) it can’t hurt to look for a bit of precision. I appreciate additional helpful contextual notes about libraries and naming conventions.
Big map, big fabric (of data, tools, people…).
2 Likes
Yes, but I quoted openstreetmap-website code which is hosted on GitHub.
Here’s another way to see that the website uses “mapnik” names internally (notice the layer parameter):
https://www.openstreetmap.org/export/embed.html?layer=mapnik
Please notice that I originally posted the comment as a “small sneak peek” and not as a feature announcement. I believe such peeks should be short and easy to read for general audience, without much detail - this will come in the final announcement.
4 Likes
Good we’re all saying this out in the open; thanks.
Edit:
I know that, though while it remains true that your link is effectively dead (correct and/or polite would be a correct one). So is your “layer parameter” containing a somewhat-dead link, as while that feature works (to export a slice of map), your specific link doesn’t enable it or cause it to interactively go to completion like Export | OpenStreetMap does (a better example, I’m merely observing).
We’re fine.
1 Like
FYI, the GitHub link that @stevea is unable to access points to a GitHub code search for files that mention “mapnik” but not “SVG”. This is the closest query using the Git Web interface, though it doesn’t filter out occurrences of “SVG”.
2 Likes
This is probably the last text update before the development server launch 
.
The project is progressing very well, and in approximately 2 weeks, it will be ready to be launched (primarily for testing, as not all features have been migrated yet). I will soon begin working on contributor documentation to finally make it a truly community project. I am super excited about all the cool stuff I want to show you all!
One last sneak peek 
. The OpenStreetMap-NG comes with a super-efficient database preload feature, where contributors can populate the database with real-world OpenStreetMap data. The data includes full element history (from the very beginning of OpenStreetMap), changesets, and dummy users from a selected country (currently Poland). The preloading process takes just 35 minutes, plus the time required to download a 4GB file. Obviously, this feature is completely optional, just for the people who need it. The preloading process only requires a contributor to run 1 basic command.
16 Likes
I failed the deadline 
but here are the screenshots to grow your appetite 
.
Now let me get back to coding.
13 Likes
How easier will it be to install OpenStreetMap NG for other projects like OpenHistoricalMap and OpenGeoFiction? It has been my dream for the core software to eventually be as easy to install as MediaWiki. 
4 Likes
I apologize for the delay in my response. Frankly, I missed your reply. As the creator of OSM-NG, I may be biased, but I believe it is generally much easier to install than the existing solution during both development and production deployments.
Development
Contributors no longer need to manually install libraries and dependencies. Everything is handled for you. You don’t even require you to have Docker nor root permissions - the PostgreSQL database runs under the current user. The only hard dependency is the Nix package manager. The system is designed from the ground up to provide high reproducibility - saving on troubleshooting time and your sanity.
Production deployments
OSM-NG offers two deployment options:
Simplified deployment (default): This embeds all necessary services within a single Docker image, eliminating the need for external database setup, migration management, and other complexities. Everything is managed internally by the startup script. This is probably what you want in most cases - and you will love it!
Advanced deployment: This allows for a decoupled database image, similar to the current OpenStreetMap infrastructure, offering more control but requiring more maintenance.
5 Likes
I understand where you are coming from. One of the challenges that deter me from starting an alternate history version of OSM is the amount of dependencies and components that I have to clone individually, from Nominatim to the main stylesheet, which I plan to recolour to fit my world’s narrative. Perhaps my poor health is partially to blame for putting off the idea for so long, though.
2 Likes
You have great progress but I’m a little scared that the API might not be very efficient when written in Python, even when using PyPy or Cython.
I’m proposing Rust + Axum!!
(Sorry I’m not allowed to put more than 3 links into a post)
https://www.rust-lang.org/what/networking
https://crates.io/crates/axum
Rust is a very fast multi-paradigm systems programming language with a very strong type system and a verbose compiler and can even be combined with existing C++ code using autocxx.
I don’t like how you’ve changed the database schema. Using only one table can (in my opinion) lead to way worse performance, since Postgres has to for example search through all relation and way rows when looking for a specific node by primary key. It’s going to be slower compared to what it is and what it could be.
Thanks for the Nix support! I can help you with making a Nix flake for making deployment as easy as services.openstreetmap-ng.enable = true; in NixOS (using flakes and having imported the repo’s NixOS module) and nix run github:Zaczero/openstreetmap-ng everywhere.
1 Like
I am not a front-end developer, but a DBA, and I have a question regarding the API+website project.
Is it necessary/mandatory that a single project includes both things (website and API) in the same repository? from my point of view the website is another API consumer, and they should be in different places.
Could we keep the API in Ruby but the new website in Python?
I feel that this integration in a single repository makes the website so heavy, and the API difficult to maintain.
As I said, I am not a front-end expert, but I know there is an initiative for an API update (Jochen Topf) and this initiative to have a Python website. By having two different projects, probably we could update the OSM website easily with more developers involved, but continue using the current API until the new one is defined.
8 Likes
So, any project that you would setup now would split the frontend from the backend. Not separating these elements makes it harder to switch frondends. Or have multiple frontends. Doing a hybrid solution with both an integrated frondend and an exposed API is also not great. As can result in things not being available in the API that are available through the integrated frontend and vice versa.
The argument could also be made that the backend API should be split up into different projects based on the responsibilities, for example splitting the editing API from the other more website specific features.
Let me explain you my perspective. Firstly, I am very proficient with Python, meaning that I can do lots of work in short amount of time with relatively low amount of bugs. I have also experience working with various libraries and I have a feel on what are the stable long-term choices. I personally wouldn’t feel comfortable with starting such a big project in a language I am not experienced in. Secondly, I want to fix various issues with the existing OSM platform, one of which being a very small pool of potential contributors (required both Ruby and C++ knowledge). Today, Python is one of the most commonly known languages and I think it’s a great choice if we want to have a successful community-run project with a wide variety of contributors. My dream is to have OpenStreetMap be one of the go-to projects even if you have just finished basic programming course; I want it to be open and simple. Thirdly, when talking about API, there are 3 main areas of computation that are worth considering.
1/3: the database, the database is responsible for filtering the data and switching the language would bring no benefit. Here, it’s all about how you structure your data in the schema, and this step is language-agnostic.
2/3: parsing database responses into entities, this second part is heavily influenced by the choice of programming language. This is where using a different language would make the most sense. Although, I believe this step is relatively small compared to the whole process and I don’t think it’s worth rising the barrier to entry just for it. If this part turns out to be worth heavy optimizations, the project should either focus on development of high-efficiency parsing Cython module (in Cython language), or Rust module with Python bindings.
3/3: response encoding (XML, JSON), this final step is already well-optimized with the use of lxml and msgspec libraries, both being written in C and scoring high in performance benchmarks. Switching to Rust and using different libraries could improve performance, but at the scale of OpenStreetMap, where responses are at most few megabytes large, this will most likely not be noticeable.
I disagree because 1st indexes and 2nd (if needed) table partitions. Those two should address your concerns, while keeping the database schema simple and easy to work with. By working with just 1 table, you reduce code complexity and make it harder to introduce bugs; especially when the data structure is so similar to each other. Your argument makes total sense on sequential scans but those should never happen at the scale of OpenStreetMap’s data — it’s all about index scans and cache.
If you know how, then sure please! The only requirement I would have is that this does not make use of Flakes mandatory to develop the project (nix-shell should continue working). I don’t like how you need to go through a few more steps just to enable Flakes support and I value a low barrier to entry. I wish Flakes were no longer experimental (then they would be enabled by default). I will note down your name and notify you when I open the project to new contributors. You can also message me directly if you have some questions. I am currently focused on final development of some core webpages and stabilizing the project.
1 Like
Replying to both @AngocA, @Tjuro
I will clarify that while initially frontend and backend will be a part of the same project, I am aware of the ideas of detaching the frontend code to a separate project and developing it in some JS framework. When developing OSM-NG, I actively avoid patterns that would make such decoupling difficult. If there is ever an initiative for a new frontend project, I will happily assist with the necessary backend changes - they will not require lots of work.
2 Likes