Did they add any form of functional nautical navigation? It always jumps to the nearest road on LAND. The feature should be removed if it doesn't work.
I've had the nautical navigation work fine when canoeing on rivers and streams where you're following linear features on the map. What it lacks is the ability to plot a sensible course across a polygon of open water.
The presence of such spines in open bodies of water just makes nautical routes come out particularly stupid, where the route presented calls for you to immediately go to that spine and travel along it, unnecessarily lengthening the route.
Same problem for pedestrian plaza structures btw.
Though there it's arguably worse as it has a good chance of affecting routing choice not just user presentation.
Any chance the profile you were using had the "snap to nearest road" option turned on? If that option was on for the profile then that would be why it jumped to the nearest road.
At this point I prefer OsmAnd navigation over Google maps.
Maps reliably does stupid things like route through winding residential streets because it thinks that's faster and can obviously be done at the full posted speed limit.
OsmAnd on the other hand builds routes I would build: get on the main road and get close, then get to the destination.
I mean, sure? But I don't do that. For city driving OsmAnd makes a sensible route which sticks to main roads whereas Google Maps was getting so bad me and my wife stopped using it because it's choices were bafflingly weird, and would do things like "make 8 turns down residential streets, then obviously make a turn across the busy 4 lane main road you could've already been driving on".
Google Maps for whatever reason routes like a residential street and turn can be negotiated at exactly the speed limit the whole way through.
I use osmand for privacy but I think it just emphasises main roads. In Melbourne it always suggests turning off cemetery road west because it doesn't know it's congested and will get me stuck for 20 minutes. And there are some missing slip roads. And navigation constantly fails to start. I wonder, how difficult is it to make minor edits to the map data?
To add, a bit complicated, but osm data can be edited with osmium (cpp) or pyosmium (python). Then the edited data can be put into osmandmapcreator to generate the file to use in Osmand. (I used this to route around ALPRs)
OsmAnd has the annoying quark of suggesting that I drive off my retaining wall, through some woods, and then across some wetlands, in order to get to the road behind my house, rather than directing me down my long driveway to the road a little further away. This is because the driveway is marked as private in the OpenStreetMap data, because it is private. Obviously I know to just go down my driveway, but anybody trying to get directions to my house would be sent to the incorrect road behind it and then just abandoned. I contacted the OsmAnd folks and was told it was an OSM problem. But other apps using OSM data don't have this issue. I gave up with OsmAnd after that.
Testing just now, it appears to not route through private roads unless it needs to (e.g. destination is on the private road) when you have that setting on, but it might just heavily down weight it so that if the public route is long enough out of the way, it will use it?
See ndriscoll's answer; but besides that there should at least be a feature to tell your local app that a road in question is not to be considered private for yourself; imagine it telling you to go around a long way instead of cutting through your private driveway road that accesses your parcel from both bottom and top road, when you don't technically have the destination on your parcel (say, going to the neighbors across the bottom street straight from work which has you come by the top street first).
A while back I was using OsmAnd on a ~700 mile route, and it was taking over 10 minutes despite most of the route ending up being on a single highway. I tried that same route just now and it took 7 seconds. Such a great improvement!
I found it able to route me to where I need to go if I decide to switch careers and become a train driver, but planning something easy like "take a bus to the train station" is impossible in OsmAnd.
We should push the typically publicly funded (and via that path: the big single entity that pays you the largest (single) share of your income as a transit company gets to dictate a LOT if they try and it's inherently close to free) to literally just publish the real time traffic information as open data for at most a fee (if getting directly from the source, not any aggregator/CDN) equal to AWS's bandwidth charges for the traffic itself.
With a license that allows others to just offer caching proxy access with no stipulations other than maybe some reasonable amounts of attribution. Because sadly many places routing with no schedule awareness increases "typical" journey times by >50% for a decent chunk of the ridership base.
On that note, I should see how open data my municipal utility's EU-forced-outcrop of a "mobility" branch handles it's real time data, because I did notice (from ads in the busses at the doors where they put what are essentially D2C "press note"s) about a year or two ago that they started offering a mobile browser usable (without giving any permissions to the site, at least above default android Chrome) live position tracker for their bus fleet.
Could be useful to do some predictive modeling on it together with the schedule to enable streaming commands to one's earbuds (if one's just listening to music while on the way) about haste (/lack thereof)/catching a different station.
Like even just telling me if I catch the bus at the closer station when leaving home or if I should walk to the other branch line which is about a minute further to walk (and that entire minute is uphill) but has the bus scheduled to depart 3 minutes later.
They connect shortly after at a transfer/crossover where the routes alternate between physically crossing and merely briefly meeting up at the same "named stop" with just two driveways separating the nominal positions at the sidewalk the busses park alongside to open their doors.
I don't have the mind to check that real-time position map for the duration of the shared walking path between home and the "fork in the road" where I have to choose between the two bus stops, while analyzing the moment on the map to identify if it's getting held up in traffic (shorter) or actually stopping at the stop it'd have to be at (AFAIK pretty much exactly) for me to not need to run (but only walk with purpose on my mind) to still catch it at the closer station.
That's particularly relevant because leaving on time with margin for retying shoelaces or stuffing mail in a backpack and aim for the father station makes me catch the closer station exactly once it's a little bit delayed (on the order of 60~90 seconds).
I'd probably want it so I tap the phone to one out of a couple NFC tags in the hallway that tell my device what kind of thing I'm about to do; be that leaving for shortly or for longer (latter case it can also cut the heating until I give it an ETA of when I'll be back; due to good insulation the savings of less thermal flux due to less temperature Delta between inside and outside are not worth having to remember to give it an ETA to have it back up to temperature before I arrive).
I don't know how everyone is getting these faster speeds. I set my navigation to HH x C++ and it still takes several minutes to calculate routes of just a couple km. I love Osmand, but bugs like these are par for the course with the app. Going back to online Graphhopper routing.
Several minutes for a few km of car driving¹ is not normal. Even the old A* method didn't take that long on my first Android phone from like 2012
If you want this obvious bug solved, you'll have to provide more info, such as
- what hardware is this on,
- what software version,
- what map version(s),
- an example route where you can reproduce it (even if that's "every route" for you, it might still be specific to your region of the world),
- which profile you have selected, assuming you haven't modified it (otherwise, export the profile so we can try it)...
I don't know how you're expecting HN to narrow down the issue from a mere "it's slow for me". You'll also have more luck in an OsmAnd community such as on https://telegram.me/OsmAndMaps or elsewhere. If you think it'll be reproducible, then the bug tracker would be the right place https://github.com/osmandapp/OsmAnd/issues
¹ maybe walking has to visit every alley and be slower if your profile modifications can't use the HH optimisation. You'll have to share details if you don't want people to have to make assumptions like this
Some of those objections to Contraction Hierarchies are possibly a little out of date. Modern variants of the technique allow for rapid live traffic customisation, see e.g. https://arxiv.org/pdf/2502.10519 . I suspect that the "nested dissection" approach also allows for regional maps.
It's been a while since I looked at OSRM's implementation, but I don't think they've been keeping up with the cutting edge here.
Yes, the idea was to transition to a variant of MLD that lends itself to the offline use case and would use an updated modeling to be more space efficient while preserving performance. There exists an incomplete (and private) PoC written in Rust.
I love osmand. But every new update seems slower. Navigation speed is mostly ok, I use it for walking and cycling which means routes tend to be short. But panning and zooming the map is just annoyingly slow. It sort of works when I disable most map features, but the map features are the reason I use osmand...
eh the reason that gmaps is not slow is due to the streaming of pre-baked maps with these features and you can check that if you go to its offline mode
I really want to stop using Google maps but the issue I have with every other option is that I can never just search for the place I want to go to. 99% of the time, the place I am going to is a business, searching "<shop name> <city name>" on anything other than Google maps either gives me nothing (OsmAnd in this category) or might give me some the shops of that chain but in a random order and intermixed with towns a hundred miles away which have the same name. More generic queries like "petrol station" are even worse. The best solution I have come up with is to use Google maps to find the actual address and then copy that into the other app but at that point I might as well just use Google maps.
I don't have solutions but I have similar experiences about this. It's probably a difficult problem since there are so many different queries and differences in the geospatial data.
Same issue, OsmAnd is great, but unless geocoding services like Nominatim get as good as Google Maps's search, I cannot use it unless I know the precise location of where I'm going.
I'm stubborn enough to use Google Maps in my web browser (signed out) and then copy/paste the actual destination address into the app for turn-by-turn directions (e.g. CoMaps, OsmAnd). It's inconvenient, but it's also one less Google app on my phone.
The Google Maps moat has always been its breadth of accurate, current business information. It is unfortunately the Yellow Pages of the Internet era.
I use simpler solution (measuring by number of taps on the screen): share place from google maps to https://f-droid.org/packages/page.ooooo.geoshare which can convert it to actual latitude/longitude which in turn can be shared to any app working with locations: OsmAnd, Organic Maps, Uber, ...
This work has been slow to take off though as the OSM community has traditionally been stuck on time wasting debates about whether opening hours displayed on the wall of a shop are copyrighted (just the raw data, not a photo of their presentation), and debating the merits and pitfalls of armchair mapping vs. on-the-ground mapping. At least these historical roadblocks seem to now be mostly resolved.
For OsmAnd, you might be able to use the OBF import feature (see https://www.osmand.net/docs/user/personal/import-export/) to add the raw ATP dataset, or potentially other open data such as Overture Maps if that is more to your liking. Data is mostly sourced direct from brand websites, APIs, etc (as if you were using a storefinder map on their website).
Interesting project osmand user here mainly in Germany.
In some cities osm data is far more accurate when t comes to opening hours or if a shop actually still exists compared to Google maps. However searching for them is a pain that one needs a bug improvement.
Since I can't rely on the search I usually try to find the poi category and click though the results,super markets,restaurants, pharmacy,atm etc works but so many cliks and caveats. Search needs massive improvement.
Absolutely. Improving this would be a great boost in usability.
I love OsmAnd and I've been using it ever since I've been using phones that can navigate. That's why I've acquired a lot of arcane knowledge on how to find places in the search function. But I could never explain to anyone what I am doing there.
It starts by the mere fact that entering a street name will always search around the current location, which is usually not where you are but the city where you last ran a lookup.
If you want to change the city, there is a tab for that. But consider using postal because sometimes the place's name may be different from what people call it. Sometimes, the same postal code appears multiple times with subsets of streets of the place. So you'll have to go for each one and look for your street. That just happened to be for Avignon (postal code 84000).
Another fun OsmAnd-introduced activity is semi-leaving German Autobahn main tracks onto the side tracks that can be used to drive off but also lead back onto the main track but with more crossing traffic. It just loves to do that.
None of such disadvantages outweigh the level of detail and possibilities in OsmAnd and further in OSM. I love knowing that I could use the same app if I once had to use a wheelchair. I love being able to add notes to a place and getting an E-Mail update months later that someone fixed an issue that I've reported.
And when I use Google Maps every once in a full moon, I run into weird little glitches that surprise me a lot because the one thing I'd expect from this marvel of our monopolistic dystopia is that it "just works" - but it really doesn't. Don't ask me what issues I ran into last time. I forgot and they've probably been replaced by more confusing ones by now :)
Nothing ready-to-go that I'm aware of. ATP will just observe in the next weekly crawl that a shop is no longer returned by the storefinder API call or sitemap crawl, and that shop will simply not be present in the next weekly dataset generated.
To set up archives of shop-specific pages (e.g. record of opening hours, address, etc at a point in time), one could monitor the latest builds of https://alltheplaces.xyz/builds.html and when a new build completes, take the new build and 2nd oldest build to compare differences. Then for any feature whose attributes have changed (address, phone number, opening hours, etc) archive the `website` and/or `source_uri` attribute pages again to ensure the latest snapshot is captured. Any new feature would get the same treatment so the page for the newly observed shop/feature is archived for the first time.
I'm also aware ArchiveTeam projects tend to commence once the impending collapse of a retail chain is known and someone realises there is a website not archived which would be useful to preserve. Monitoring of ATP feature counts for brands across time may give some hint of how a brand is performing and whether it is growing or shrinking without having to find press releases and financial statements of the brand. Even if a brand suddenly announces bankruptcy (it happens all the time), generally the website will remain online for at least a few months whilst a new buyer is sought or whilst each retail location has a fire sale to get rid of remaining merchandise. It's also worthwhile to be aware of acquisitions of retail chains as this often results in the new parent company changing websites soon after acquisition closes, possibly removing useful content that once existed. Websites also change "just because" and this could be observed after-the-fact by seeing when ATP spiders break and get replaced/fixed.
Your best bet is probably to look for wikidata entries that are marked defunct; and match up to something like name-suggestion-index to get broad categories.
Also, one of the best projects that help with that "last mile" is StreetComplete (https://streetcomplete.app/ available in Google Plasy and F-droid), it makes quite easy to add e.g. opening hours to shops.
I built a geocoder that mostly solves this https://jonready.com/blog/posts/geocoder-for-ai-agents.html. I have about 96% recall compared to google places 98% recall, but it uses an llm for query planning and ranking so it might not be a good solution for you.
No solution. I am a big fan of OSM, but modern maps are not about street namesabd building, but about POI. When you go/drive somewhere you are going to store/museum/pharmacy and so on. If this data isn't reliable it's useless. Additional information like phone number, working hours and website is next level which isn't achievable by OSM.
Years ago I bought Sygic lifetime one, and it has offline maps with updates. Although I don’t use it as much anymore, but it was so accurate, and that was before google nav too.
CoMaps is by far one of the best offline navigation map app available.
They forked from Organic Maps project which seems to have gone evil.
CoMaps calculation is very fast, map update is constant, it is very lightweight, it has a very clean layout, usability is top tier.
CoMaps can find places by the business name, there is still room for improvement but it works.
I was using EarthMagic before that, it was the perfect 10/10 opensource app until they went greedy, and the app now has tons of problems.
I went back to Sygic which is an awesome offline map app, I have a lifetime Premium licensing and as expected, now there is a Premium Plus license which some features were moved to like TTS and limited map update.
CoMaps also works really well with Android Auto and I am running GrapheneOS, it was actually somebody within GOS who recommended it to me.
CoMaps also display trains line, buses stops, public toilets, even motorcycle parking.
If you are tired of dramas, give CoMaps a go.
CoMaps is available via Codeberg opensource alternative to GitHub and they are pretty active towards reporting issues.
The community forked and created comaps because the organic maps maintainers were unwilling to listen to the community, taking decisions that the community disapproved of.
Comaps seems to be more active than organic maps today
If you would make the effort to compare commits, you'll see that contributors for Co are mostly fiddling with:
- the UI (pixels here, different label or color here - just check the commits by "Yannik Bloscheck"!)
- adding objects to the map, which are not often justified (like rendering single(!) trees and tree rows, which is from a performance POV insane)
- translations / strings
They rarely touch navigation, the engine, or sensible refactoring tasks.
The whole project lacks organization and clear, structured goals. Ever heard about too many cooks?
It was, especially to the agitators like Konstantin "Pastbin", more important to obtain increased authority and power and their own branfing, while complaining about financing and perceived transparency issues; this were huge contributing factors for the split.
I couldn't give a rats about how donations are spend or if there's a "community council" or a registered entity behind a tradematk / app, if the outcome / product is suitable.
What i care about is an organized vision and structured approach by founders.
PS: The CDN middleware ("map generator") was made closed source due to too many freeloaders hogging onto their map CDN. Get your facts straight.
Making map generator proprietary won't help to solve "freeloaders hogging onto their map CDN" issue.
In fact, it actually forces potential forks to use their CDN because they can't setup their own map generation (as its closed source).
The OM's map generator was made proprietary in order to hinder the right to fork and enforce vendor lock-in. Later, a proprietary "Data License" had been introduced for binary files (incl. maps) with the same goal - effectively one can't build/fork OM without these files anymore.
Hi Alex! Talking about yourself in third person again? Sorry I haven't made enough new features for you lately, I've been a little busy. I'll do better for you, I promise. I wish that our attempts to formally communicate and resolve concerns weren't considered "pathetic" but c'est la vie.
I "fell" for Comaps but switched back to Organic Maps (where the original real good devs are). Comaps felt a bit too much like fork, "fabricate" nice media and beg for donations. Both are imho inferior to (non-foss) Magic Earth but consume much less power.
We've actually massively held off on begging for donations -- for example we removed the ability of the app to dynamically insert ads into the menus or change the home button to a icon, and massively scaled back our end-of-year fundraising post because we actually have a decent amount of money in the bank. Instead we've chosen to thank contributors for funding our ability to afford better servers etc. What we need more than more money is more volunteerism, which we're happy to see increasing every day!
Stay tuned to CoMaps, we've been releasing two updates with maps per month lately and soon will be able to release maps as often as our servers will allow!
Could anyone explain, please, where's the 100x acceleration they mention? The screen records compare 36 seconds to 13 seconds, that's roughly 3x.
Also, this piece:
> 100x speedup is achieved by comparing HH with bidirectional A*. 2-phase A* already uses many heuristics which don't always create an optimal route and still 5-10x slower.
So, 2-phase A* is 5-10x slower than bidirectional A*?
The part you cited explains it. The 100x speedup is achieved by comparing to a method they didn't use anyway because it was too slow, but one that would find an optimal route like HH presumably does—when you have the default profiles and not a custom vehicle speed (like me who doesn't drive 130km/h because it's marginal gains for exponential fuel/CO2 use, so I configured the routing engine to find the best route for a vehicle with max speed 105)
Assuming "slang" is an exaggeration: the basic principle of OSM is that things are mapped and named as they are on the ground. So local names and naming conventions should work; if they don't, it's a bug.
An easy way to contribute to OSM is by using Street Complete (https://streetcomplete.app/) which asks questions about one's surroundings.
"This app finds missing map data in your vicinity and displays it on a map as quests. Solve each quest by visiting the location on-site and answering a simple question to update the map."
tencentshill | a day ago
wtallis | a day ago
RunningDroid | a day ago
https://wiki.openstreetmap.org/wiki/Key:area:highway#Routers
https://wiki.openstreetmap.org/wiki/Proposal:Area_highway/ma...
wtallis | 21 hours ago
namibj | 11 hours ago
pwg | a day ago
teddyh | a day ago
XorNot | a day ago
Maps reliably does stupid things like route through winding residential streets because it thinks that's faster and can obviously be done at the full posted speed limit.
OsmAnd on the other hand builds routes I would build: get on the main road and get close, then get to the destination.
greenavocado | a day ago
XorNot | a day ago
Google Maps for whatever reason routes like a residential street and turn can be negotiated at exactly the speed limit the whole way through.
macintux | a day ago
brendyn | a day ago
evertheylen | a day ago
pwg | a day ago
The map data is OpenStreetMap, so you can make edits via the standard OSM methods:
Web: https://ideditor.com/
Local: https://josm.openstreetmap.de/
ndriscoll | 21 hours ago
gentile | 20 hours ago
technothrasher | a day ago
yaomtc | a day ago
snozolli | a day ago
ndriscoll | 21 hours ago
namibj | 11 hours ago
ndriscoll | 21 hours ago
https://wiki.openstreetmap.org/wiki/Tag:access%3Ddestination
interloxia | 12 hours ago
pavon | a day ago
lejalv | a day ago
I would at once get the 15-year XV plan if they got this, but perhaps it's at odds with their motto “Offline Maps and Navigation”?
(even if I personally could live with schedule-based routing, i.e. not real-time routing, at least for a while).
yorwba | a day ago
schaum | 16 hours ago
2Gkashmiri | 15 hours ago
yorwba | 13 hours ago
jeroenhd | 13 hours ago
namibj | 11 hours ago
namibj | 11 hours ago
On that note, I should see how open data my municipal utility's EU-forced-outcrop of a "mobility" branch handles it's real time data, because I did notice (from ads in the busses at the doors where they put what are essentially D2C "press note"s) about a year or two ago that they started offering a mobile browser usable (without giving any permissions to the site, at least above default android Chrome) live position tracker for their bus fleet.
Could be useful to do some predictive modeling on it together with the schedule to enable streaming commands to one's earbuds (if one's just listening to music while on the way) about haste (/lack thereof)/catching a different station.
Like even just telling me if I catch the bus at the closer station when leaving home or if I should walk to the other branch line which is about a minute further to walk (and that entire minute is uphill) but has the bus scheduled to depart 3 minutes later. They connect shortly after at a transfer/crossover where the routes alternate between physically crossing and merely briefly meeting up at the same "named stop" with just two driveways separating the nominal positions at the sidewalk the busses park alongside to open their doors.
I don't have the mind to check that real-time position map for the duration of the shared walking path between home and the "fork in the road" where I have to choose between the two bus stops, while analyzing the moment on the map to identify if it's getting held up in traffic (shorter) or actually stopping at the stop it'd have to be at (AFAIK pretty much exactly) for me to not need to run (but only walk with purpose on my mind) to still catch it at the closer station. That's particularly relevant because leaving on time with margin for retying shoelaces or stuffing mail in a backpack and aim for the father station makes me catch the closer station exactly once it's a little bit delayed (on the order of 60~90 seconds).
I'd probably want it so I tap the phone to one out of a couple NFC tags in the hallway that tell my device what kind of thing I'm about to do; be that leaving for shortly or for longer (latter case it can also cut the heating until I give it an ETA of when I'll be back; due to good insulation the savings of less thermal flux due to less temperature Delta between inside and outside are not worth having to remember to give it an ETA to have it back up to temperature before I arrive).
szewachvice | a day ago
Aachen | 8 hours ago
If you want this obvious bug solved, you'll have to provide more info, such as
- what hardware is this on,
- what software version,
- what map version(s),
- an example route where you can reproduce it (even if that's "every route" for you, it might still be specific to your region of the world),
- which profile you have selected, assuming you haven't modified it (otherwise, export the profile so we can try it)...
I don't know how you're expecting HN to narrow down the issue from a mere "it's slow for me". You'll also have more luck in an OsmAnd community such as on https://telegram.me/OsmAndMaps or elsewhere. If you think it'll be reproducible, then the bug tracker would be the right place https://github.com/osmandapp/OsmAnd/issues
¹ maybe walking has to visit every alley and be slower if your profile modifications can't use the HH optimisation. You'll have to share details if you don't want people to have to make assumptions like this
n4r9 | a day ago
It's been a while since I looked at OSRM's implementation, but I don't think they've been keeping up with the cutting edge here.
DennisL123 | 14 hours ago
n4r9 | 10 hours ago
https://github.com/Project-OSRM/osrm-backend/issues/6574
DennisL123 | 4 hours ago
elric | 23 hours ago
nicman23 | 11 hours ago
charlie-83 | 23 hours ago
Anyone have any solutions to this?
rzmmm | 23 hours ago
dobladov | 23 hours ago
matkoniecz | 22 hours ago
(I have an ongoing project attempting to make slightly easier to detect and add missing ones but it will be just tiny step forward, not solution)
Aachen | 9 hours ago
sfRattan | 20 hours ago
The Google Maps moat has always been its breadth of accurate, current business information. It is unfortunately the Yellow Pages of the Internet era.
Self-Perfection | 10 hours ago
ihatehn | 3 hours ago
dhx | 20 hours ago
This work has been slow to take off though as the OSM community has traditionally been stuck on time wasting debates about whether opening hours displayed on the wall of a shop are copyrighted (just the raw data, not a photo of their presentation), and debating the merits and pitfalls of armchair mapping vs. on-the-ground mapping. At least these historical roadblocks seem to now be mostly resolved.
For OsmAnd, you might be able to use the OBF import feature (see https://www.osmand.net/docs/user/personal/import-export/) to add the raw ATP dataset, or potentially other open data such as Overture Maps if that is more to your liking. Data is mostly sourced direct from brand websites, APIs, etc (as if you were using a storefinder map on their website).
schaum | 16 hours ago
In some cities osm data is far more accurate when t comes to opening hours or if a shop actually still exists compared to Google maps. However searching for them is a pain that one needs a bug improvement.
Since I can't rely on the search I usually try to find the poi category and click though the results,super markets,restaurants, pharmacy,atm etc works but so many cliks and caveats. Search needs massive improvement.
eloeffler | 12 hours ago
Absolutely. Improving this would be a great boost in usability.
I love OsmAnd and I've been using it ever since I've been using phones that can navigate. That's why I've acquired a lot of arcane knowledge on how to find places in the search function. But I could never explain to anyone what I am doing there.
It starts by the mere fact that entering a street name will always search around the current location, which is usually not where you are but the city where you last ran a lookup.
If you want to change the city, there is a tab for that. But consider using postal because sometimes the place's name may be different from what people call it. Sometimes, the same postal code appears multiple times with subsets of streets of the place. So you'll have to go for each one and look for your street. That just happened to be for Avignon (postal code 84000).
Another fun OsmAnd-introduced activity is semi-leaving German Autobahn main tracks onto the side tracks that can be used to drive off but also lead back onto the main track but with more crossing traffic. It just loves to do that.
None of such disadvantages outweigh the level of detail and possibilities in OsmAnd and further in OSM. I love knowing that I could use the same app if I once had to use a wheelchair. I love being able to add notes to a place and getting an E-Mail update months later that someone fixed an issue that I've reported.
And when I use Google Maps every once in a full moon, I run into weird little glitches that surprise me a lot because the one thing I'd expect from this marvel of our monopolistic dystopia is that it "just works" - but it really doesn't. Don't ask me what issues I ran into last time. I forgot and they've probably been replaced by more confusing ones by now :)
pabs3 | 16 hours ago
https://wiki.archiveteam.org/
dhx | 15 hours ago
To set up archives of shop-specific pages (e.g. record of opening hours, address, etc at a point in time), one could monitor the latest builds of https://alltheplaces.xyz/builds.html and when a new build completes, take the new build and 2nd oldest build to compare differences. Then for any feature whose attributes have changed (address, phone number, opening hours, etc) archive the `website` and/or `source_uri` attribute pages again to ensure the latest snapshot is captured. Any new feature would get the same treatment so the page for the newly observed shop/feature is archived for the first time.
I'm also aware ArchiveTeam projects tend to commence once the impending collapse of a retail chain is known and someone realises there is a website not archived which would be useful to preserve. Monitoring of ATP feature counts for brands across time may give some hint of how a brand is performing and whether it is growing or shrinking without having to find press releases and financial statements of the brand. Even if a brand suddenly announces bankruptcy (it happens all the time), generally the website will remain online for at least a few months whilst a new buyer is sought or whilst each retail location has a fire sale to get rid of remaining merchandise. It's also worthwhile to be aware of acquisitions of retail chains as this often results in the new parent company changing websites soon after acquisition closes, possibly removing useful content that once existed. Websites also change "just because" and this could be observed after-the-fact by seeing when ATP spiders break and get replaced/fixed.
throwaway346434 | 8 hours ago
krzyk | 8 hours ago
kqr | 16 hours ago
This is what I do.
> but at that point I might as well just use Google maps.
I disagree. OSMAnd is so much more user-friendly as a map. Google Maps is a great business locator, but that's all it really does well.
Here's a comparison, albeit this uses openstreetmap.org rather than OSMAnd: https://i.xkqr.org/gmapsvsosm.png
mips_avatar | 12 hours ago
HunOL | 12 hours ago
No solution. I am a big fan of OSM, but modern maps are not about street namesabd building, but about POI. When you go/drive somewhere you are going to store/museum/pharmacy and so on. If this data isn't reliable it's useless. Additional information like phone number, working hours and website is next level which isn't achievable by OSM.
pwg | 3 hours ago
Whether it is present in any given area depends upon whether someone bothered to add it to OSM.
faryalbukhari | 8 hours ago
tamimio | 22 hours ago
h4kunamata | 21 hours ago
They forked from Organic Maps project which seems to have gone evil.
CoMaps calculation is very fast, map update is constant, it is very lightweight, it has a very clean layout, usability is top tier. CoMaps can find places by the business name, there is still room for improvement but it works.
I was using EarthMagic before that, it was the perfect 10/10 opensource app until they went greedy, and the app now has tons of problems.
I went back to Sygic which is an awesome offline map app, I have a lifetime Premium licensing and as expected, now there is a Premium Plus license which some features were moved to like TTS and limited map update.
CoMaps also works really well with Android Auto and I am running GrapheneOS, it was actually somebody within GOS who recommended it to me.
CoMaps also display trains line, buses stops, public toilets, even motorcycle parking. If you are tired of dramas, give CoMaps a go.
CoMaps is available via Codeberg opensource alternative to GitHub and they are pretty active towards reporting issues.
lorenzohess | 21 hours ago
TheLNL | 18 hours ago
Comaps seems to be more active than organic maps today
h4kunamata | 16 hours ago
When you have an option like CoMaps that is opensource friendly and very active, I got 2 maps updates within like 2 weeks, you already lost it all.
What I am impressed with is the app, it is so clean, polished and well designed so is the map.
CamelCaseCondo | 13 hours ago
ihatehn | 3 hours ago
twocommits | 11 hours ago
- the UI (pixels here, different label or color here - just check the commits by "Yannik Bloscheck"!)
- adding objects to the map, which are not often justified (like rendering single(!) trees and tree rows, which is from a performance POV insane)
- translations / strings
They rarely touch navigation, the engine, or sensible refactoring tasks.
The whole project lacks organization and clear, structured goals. Ever heard about too many cooks?
It was, especially to the agitators like Konstantin "Pastbin", more important to obtain increased authority and power and their own branfing, while complaining about financing and perceived transparency issues; this were huge contributing factors for the split.
I couldn't give a rats about how donations are spend or if there's a "community council" or a registered entity behind a tradematk / app, if the outcome / product is suitable.
What i care about is an organized vision and structured approach by founders.
PS: The CDN middleware ("map generator") was made closed source due to too many freeloaders hogging onto their map CDN. Get your facts straight.
pastk | 9 hours ago
The OM's map generator was made proprietary in order to hinder the right to fork and enforce vendor lock-in. Later, a proprietary "Data License" had been introduced for binary files (incl. maps) with the same goal - effectively one can't build/fork OM without these files anymore.
twocommits | 4 hours ago
ihatehn | 3 hours ago
chappi42 | 8 hours ago
ihatehn | 3 hours ago
Stay tuned to CoMaps, we've been releasing two updates with maps per month lately and soon will be able to release maps as often as our servers will allow!
eisa01 | 17 hours ago
h4kunamata | 16 hours ago
They all start "for the community", become too big, go greedy, and forget that projects/company is nothing without users.
pastk | 9 hours ago
Aachen | 8 hours ago
culebron21 | 15 hours ago
Also, this piece:
> 100x speedup is achieved by comparing HH with bidirectional A*. 2-phase A* already uses many heuristics which don't always create an optimal route and still 5-10x slower.
So, 2-phase A* is 5-10x slower than bidirectional A*?
nicman23 | 11 hours ago
dominicrose | 9 hours ago
Routing type (Android) / Routing algorithm (iOS)
- A* 2-phase (Android) / A* (iOS)
- A classic* (Android) / Highway hierarchies (iOS)
- HH (Highway Hierarchies) x C++ (Android only)
Aachen | 8 hours ago
pluto_modadic | 14 hours ago
nicman23 | 11 hours ago
pferde | 10 hours ago
OsmAnd merely makes use of the data from OSM.
SahAssar | 6 hours ago
gpvos | 5 hours ago
gpvos | 5 hours ago
B5C8ECB24DB47D1 | 11 hours ago
"This app finds missing map data in your vicinity and displays it on a map as quests. Solve each quest by visiting the location on-site and answering a simple question to update the map."
Available from f-droid.