> I don't think they were very edge-y from what I remember... but I'll double check. And will get a screenshot if I disagree - maybe it's something about window size or display density.
For some reasons, the results drawn on the map are more numerous than the ones we show in the result list. I've raised an issue to investigate this. https://codeberg.org/cartes/web/issues/2480
> But if that category search is not enabled, why doesn't it find business name matches? And why are the results far outside the viewing window?
Good question. It's a Photon (our search API) problem as far as I know. We probably did set a local search ponderation too low for this use case.
In case the user chose the (default) "search here" option, we could also add a proximity ranking.
I do agree with your last big paragraph : we don't have Google's budget, hence the "search here" option which already solved lots of dead ends. Thanks a lot for this discussion !
Thanks, it lets me understand the bugs that make coffees impossible to be found for you. The first problem is that for performance reasons, we don't enable category discovery and search at high zoom. They only appear at zoom 13 (https://cartes.app/#13.7/43.04398/-87.911), and your link was at zoom 12.41. This category suggestion would have let you show all coffee places on the map. But not yet filter your searches to this category only, that will be a game-changer feature we're working on.
The zoom limitation is a known problem, but probably worse in the US where cities are less dense than in Europe. I'll prioritize it, thanks.
2nd problem is that the "coffee" word doesn't trigger the coffee category. It should, I'll investigate too.
On your link, two Valentine coffee are shown on the map with the query "valentine", but none are in the search results list, and they're on the edges of the map. Interesting bug : probably a side effect of adding address search last week, I'll investigate.
You're probably our first US-user test, thanks again :)
We're not using Bluesky, but Atproto ;)
So place reviews is federated and open-source : we use Eurosky/Mu.social daily for our social accounts.
Also, Bluesky itself is open-source.
> but I think the international version is still work in progress, so I'll gladly return in the future.
Do you know of any of these public bodies that would have the agility and competence to back such a project ? I don't.
In France, where cartes.app is built and incorporated, the government is far from being ideologically equipped to envision the launch a (privacy-focused) general public map application. IGN provides map, but they are still far from a general public usage, they're more useful for experts.
Even the professional office suite dedicated to agents (LaSuite) is in risk because it's said to destroy French companies (trying to) deliver these tools.
Meanwhile, a private company, if necessary with capped profits and salaries, seems by far the most practical solution in my experience. Hence the choice.
> So you want the public to fund your business and what it gets in return is the honour of improving your business and "compete with Big Tech"?
To fund an open-source and open-data business, yes.
> I think there's a strong incentive to take their chances with Big Tech until a better alternative pops up.
How do you think an alternative to duopolistic apps valued hundreds of billions could emerge without funding ? The problem is hard, we know it. We think the startup way, raising millions for a map app to compete with Google, has less chances of success than building a modern common.
> In my view, a public service should benefit (and be controlled by) the public.
Isn't open-source software the closer model to what you desire ? A "public" map app in the sense of "developed and hosted by the government" could enable large funding, but could also be quite frightening.
Actually, it's one of the reasons some Europeans want to quit Google & Apple maps : on top of being economic mastodons, they are excessively close to the US, a state that has gone the way of government corruption, to say the least.
You're right. Last holidays, I went to beautiful place in Spain. A way covered in Ferns was marked as an OSM path. I guess it was, but did not get cut this year or the later. So we tried and failed 30 m after.
It's important to keep some mysteries despite precise maps.
That's why I'm at the same time fascinated by 3D "splats", but also worried to be spoiled.
They're great for places we already know (inspect your roof's shape for instance), but they spoil discovery.
In the app I'm developing, cartes.app, we acknowledged this lack of pictures.
We show local Wikimedia common pictures, osm tag pictures, og:image pictures of the website if any, Wikipedia article infobox pictures, Panoramax for street-view, and last but not least, any picture dropped by an ATproto place review.
Lots remain to be done, especially building the latter community of reviews.
Could you try https://cartes.app and share your search terms and expectations ? We're using Photon, an OpenSearch search engine. We've build a dictionary of place categories to help in-browser with FuseJS.
Also thinking about using embeddings to complement this.
For good (server) search, one needs many layers (Photon, Pelias with OpenAdresses, Overpass, in-house pmtiles, etc.) using many DBs, each needing server ressources or expensive paid APIs.
It's obvioulsy expensive in terms of ops + dev, but also just to host.
It can't scale with only 0,0001 % of users donating to the app.
Fortunately, NLNet's there to fund work, but it's still nonethless only a tenth of what would be needed.
Plus map applications and general search engines don't talk to each other... I don't know why, but it is so. Maybe because all the well-known search engines are closed-source ?
It doesn't take so much to enable a good server search on top of OSM + openaddresses.
Local search will always be slow and bad.
But server search doesn't need that much. It's just that OS initiatives are severely understaffed. OS apps that have a Photon instance are already rare to find. Let's not talk about having an Overpass instance...
What is very hard to reproduce is Google's place review data.
For some reasons, the results drawn on the map are more numerous than the ones we show in the result list. I've raised an issue to investigate this. https://codeberg.org/cartes/web/issues/2480
> But if that category search is not enabled, why doesn't it find business name matches? And why are the results far outside the viewing window?
Good question. It's a Photon (our search API) problem as far as I know. We probably did set a local search ponderation too low for this use case.
In case the user chose the (default) "search here" option, we could also add a proximity ranking.
I do agree with your last big paragraph : we don't have Google's budget, hence the "search here" option which already solved lots of dead ends. Thanks a lot for this discussion !