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.
