comaps/url-processor
21
4
Fork
You've already forked url-processor
1

Improve web POI viewer #16

Open
opened 2025年06月07日 14:32:07 +02:00 by jeanbaptisteC · 9 comments
Contributor
Copy link

Actually, we use leaflet to shown on comaps.app an map with poi marker.
We can try to find a better web experience for final users.

I suggest two OSM web app which support iframe:

WDYT? @hb0nd @pastk

Actually, we use leaflet to shown on comaps.app an map with poi marker. We can try to find a better web experience for final users. I suggest two OSM web app which support iframe: - https://osmapp.org/en/relation/65606#17.00/51.4893/-0.1441 - https://cartes.app/?allez=Londres%7Cr65606%7C-0.1278%7C51.5074 WDYT? @hb0nd @pastk

cartes.app just added English, maybe it's a possibility again?

@thesupertechie are you still wanting to try to roll your own?

cartes.app just added English, maybe it's a possibility again? @thesupertechie are you still wanting to try to roll your own?

I'm not sure about using cartes.app tbh: Beyond them going down the LLM-dev route (based on the agents file in their repo), they also seem to consider switching to a subscription model? See cartes/web#2072 (comment)

I'm not sure about using cartes.app tbh: Beyond them going down the LLM-dev route (based on the agents file in their repo), they also seem to consider switching to a subscription model? See https://codeberg.org/cartes/web/issues/2072#issuecomment-13586489

We discuss all possible funding options in this ticket, not just the subscription. But in any case, NLnet’s funding for Mael is coming to an end soon, so we’ll need to find other sources of funding if we want to ensure maintenance (Mael is solely responsible for managing the infrastructure) and continue development at the same pace.

Perhaps one solution for you could be to deploy a cartes.app instance reserved for CoMaps users. I’m only thinking about the frontend part, as I think you could probably use our backend.
Mael has done a great job of automating the frontend deployment. When the server was corrupted a few months ago, he was able to redeploy the instance within a few hours. Please feel free to discuss this with him.

We discuss all possible funding options in this ticket, not just the subscription. But in any case, NLnet’s funding for Mael is coming to an end soon, so we’ll need to find other sources of funding if we want to ensure maintenance (Mael is solely responsible for managing the infrastructure) and continue development at the same pace. Perhaps one solution for you could be to deploy a cartes.app instance reserved for CoMaps users. I’m only thinking about the frontend part, as I think you could probably use our backend. Mael has done a great job of automating the frontend deployment. When the server was corrupted a few months ago, he was able to redeploy the instance within a few hours. Please feel free to discuss this with him.

We're definitely happy to self host. We also have some that could theoretically be used to fill gaps in our abilities or support partner projects. (We've considered donating to Codeberg for example, though haven't begun such a process yet)

We're definitely happy to self host. We also have some $$ that could theoretically be used to fill gaps in our abilities or support partner projects. (We've considered donating to Codeberg for example, though haven't begun such a process yet)

@zyphlar wrote in #16 (comment):

cartes.app just added English, maybe it's a possibility again?

@thesupertechie are you still wanting to try to roll your own?

Completely forgot about it. Will take a look when I get a chance.

@zyphlar wrote in https://codeberg.org/comaps/url-processor/issues/16#issuecomment-13618277: > cartes.app just added English, maybe it's a possibility again? > > @thesupertechie are you still wanting to try to roll your own? Completely forgot about it. Will take a look when I get a chance.

Hi ! As mentionned above, we're now international !

Of course i18n is an infinite task and some of our code has no tag yet, so these figures are not absolute, but we're progressing fast.


image
.

Hi ! As mentionned above, we're now international ! Of course i18n is an infinite task and some of our code has no <Trans> tag yet, so these figures are not absolute, but we're progressing fast. [ ![image](/attachments/67187821-3c3a-4a1e-bbc8-0e4e30028996)](https://translate.codeberg.org/projects/cartes/web/messages/).
142 KiB

I'm not sure about using cartes.app tbh: Beyond them going down the LLM-dev route (based on the agents file in their repo), they also seem to consider switching to a subscription model? See cartes/web#2072 (commentaire)

Yes we're using (european) LLMs to help us build some features. It's the responsability of each dev to proof-read everything that is output by any LLM before commiting. In a similar manner, LLMs help us translate the website in languages that we don't master, and are useful even for languages we know : translating a full app is a long task. We're severely constrained by the lack of human contribution to our project : they are useful tools and we known their limits. LLMs were particularly useful to help us build our Ansible full automated deployment stack.

they also seem to consider switching to a subscription model? See cartes/web#2072 (commentaire)

Yes, we need money. We respect Comaps' decision to go for a donation model, but I believe cartes.app is a service more than a non-profit. These donations will first serve to cover our ~ 500 €/month hosting and paid API bills. And then, pay the thousands of hours of development that we need to offer a proper open-source competitor to Google & Apple Maps. We hope to have enough paid users to offer a free base service to most people. The subscription system was launched 3 weeks ago : it's a single 3 € / trimester plan, offering the satellite style. This style costs us a linear bill, currently 100 €/month with our still modest trafic.

Our code is 100 % open-source and almost 80 % automatised (except for Overpass deployment, we maintain 3 instances and it's deployed by hand for now) and can thus be forked by any contributor or third-party actor that would want to try another path, without any subscription model. The only constraint is AGPL.

Would be happy to work with Comaps for a Web version :)

> I'm not sure about using cartes.app tbh: Beyond them going down the LLM-dev route (based on the agents file in their repo), they also seem to consider switching to a subscription model? See cartes/web#2072 (commentaire) Yes we're using (european) LLMs to help us build some features. It's the responsability of each dev to proof-read everything that is output by any LLM before commiting. In a similar manner, LLMs help us translate the website in languages that we don't master, and are useful even for languages we know : translating a full app is a long task. We're severely constrained by the lack of human contribution to our project : they are useful tools and we known their limits. LLMs were particularly useful to help us build our Ansible full automated deployment stack. > they also seem to consider switching to a subscription model? See cartes/web#2072 (commentaire) Yes, we need money. We respect Comaps' decision to go for a donation model, but I believe cartes.app is a service more than a non-profit. These donations will first serve to cover our ~ 500 €/month hosting and paid API bills. And then, pay the thousands of hours of development that we need to offer a proper open-source competitor to Google & Apple Maps. We hope to have enough paid users to offer a free base service to most people. The subscription system was launched 3 weeks ago : it's a single 3 € / trimester plan, offering the satellite style. This style costs us a linear bill, currently 100 €/month with our still modest trafic. Our code is 100 % open-source and almost 80 % automatised (except for Overpass deployment, we maintain 3 instances and it's deployed by hand for now) and can thus be forked by any contributor or third-party actor that would want to try another path, without any subscription model. The only constraint is AGPL. Would be happy to work with Comaps for a Web version :)

@laem if we had a self-hosted cartes.app fork, wouldn't that take away from your income model? What would be the benefit to you?

@laem if we had a self-hosted cartes.app fork, wouldn't that take away from your income model? What would be the benefit to you?

Well yes if you self-host with a comaps rebranding that never redirects to cartes.app and without any contribution to our codebase nor without any financial contribution, that would not help us directly. We could probably find a way to help both our projects, though, if self-hosting is a necessary condition for Comaps. On the side, using our ATProto place review system would help build a critical mass, and this is an example among many. Just hosting cartes.app would probably lead to useful contributions to our Ansible roles or consolidation of our 10 + services running on our servers already.

For our part, we don't want to clone Comaps and publish it as "Cartes.app" nor build a native app, but redirect the user to Comaps when they need it. Two use cases are clear : "I want offline maps for my trip / hike" and "I want a first-person navigation app". In the long term, I don't think users can cope with the complexity of juggling between 2 or 3 apps : they need the simplicity of a single map brand that does everything. But in practice, organisations exist, and let's not forget that Google is a successful two-headed leading horse (Google Maps + Waze).

Building a good Web map is a complex task of its own, we're focused 1000 % on it (meaning : we'd need 10 x more resources to build it). I guess building a good native offline map is also a 1000 % task and even hosting cartes.app on your servers could take precious time for your team.

Also, we should remember how small we are in comparison to our competitors.

This recent survey by the French map agency tells everything (for France, but it's probably similar in all Europe) about how many users we still need to convince : about 99 %, taking "OpenStreetMap" as the line that includes all of our libre projects.

Komoot's 1 % was sufficient to be bought 300 million € (I guess Komoot was larger in Germany, but you get the idea).

image
source

Well yes if you self-host with a comaps rebranding that never redirects to cartes.app *and* without any contribution to our codebase nor without any financial contribution, that would not help us directly. We could probably find a way to help both our projects, though, if self-hosting is a necessary condition for Comaps. On the side, using our ATProto place review system would help build a critical mass, and this is an example among many. Just hosting cartes.app would probably lead to useful contributions to our Ansible roles or consolidation of our 10 + services running on our servers already. For our part, we don't want to clone Comaps and publish it as "Cartes.app" nor build a native app, but redirect the user to Comaps when they need it. Two use cases are clear : "I want offline maps for my trip / hike" and "I want a first-person navigation app". In the long term, I don't think users can cope with the complexity of juggling between 2 or 3 apps : they need the simplicity of a single map brand that does everything. But in practice, organisations exist, and let's not forget that Google is a successful two-headed leading horse (Google Maps + Waze). Building a *good* Web map is a complex task of its own, we're focused 1000 % on it (meaning : we'd need 10 x more resources to build it). I guess building a *good* native offline map is also a 1000 % task and even hosting cartes.app on your servers could take precious time for your team. Also, we should remember how small we are in comparison to our competitors. This recent survey by the French map agency tells everything (for France, but it's probably similar in all Europe) about how many users we still need to convince : **about 99 %**, taking "OpenStreetMap" as the line that includes all of our libre projects. Komoot's 1 % was sufficient to be bought 300 million € (I guess Komoot was larger in Germany, but you get the idea). ![image](/attachments/eb028059-86dd-4c2a-8132-bb062892ccfb) [source](https://www.ign.fr/files/default/2026-06/Enquete_Ipsos_Bva_IGN_Juin-2026.pdf)
172 KiB
Sign in to join this conversation.
No Branch/Tag specified
master
ci
rt-geo-links
No results found.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
comaps/url-processor#16
Reference in a new issue
comaps/url-processor
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?