I made a version of this too. My favorite features is that you can get snippets of articles and have them read aloud (great for roadtrips). https://calebkruse.com/wikitrip/
I currently live in a nondescript suburb of Los Angeles(Woodland Hills) and I’m always looking for interesting things to do in my area. This fits the bill exactly.
Also really liked the animation of the map when I typed in my area.
I'm quite a big fan of this idea. There is a lot of local history that I suspect I'd never have learned about if some map like this didn't exist.
The one thing that would greatly streamline my own usage is a direct link to the Wikipedia page on the pin itself (without having to open the pin, wait for the modal, scroll to the Wikipedia link, then click through). I'm clicking around the local spots and opening the Wikipedia pages for the interesting locations in new tabs to read them all at once.
So this must only work in urban/metro areas. In my rural area, it's just a map of incorporated townships, and I know there are historical things in this area that are on wikipedia.
In my metro area it's mostly just articles about specific buildings which is interesting if you're a building nerd, not so much if you're not. On an imaginary notability scale, they'd all be on the bottom rung meeting just the minimum to be included in Wikipedia.
Next steps on this kind of thing would be to classify the nearby items and then give them a score for how interesting they were.
This is a bus station. I have no idea why a bus station meets the qualifications to be included in Wikipedia in the first place, but it's definitely not an "interesting place nearby".
I love this so much, I’ve wanted this for SO long - thank you. I often am traveling between major cities and think “you know, I bet there’s a lot of interesting history and ecology right here. I bet some people would come from far and wide to be right here. I wish I knew a local who could tell me about it…”
If anyone wants to steal my million dollar startup idea, please credit my HN username in your IPO announcement: we need an app that integrates simple itinerary creation (airbnb/tripadvisor/google-sheets), itinerary management (tripit), restaurant selection (yelp), expense tracking (Splitwise), and this (ad-hoc location-based information of a vaguely “historical” or “informative” nature). Of course all with a sprinkling of LLM-magic on top for UX niceties.
So one app could connect a group over the course of a trip, helping them plan it both in advance and in the moment. Call it… _The Worldbook_.
Very nice idea but useless in Paris. Dots are grouped too aggressively and don't have captions. Need to ungroup and click on each, gave up after checking 20 metro stations and landmarks I already know. Filters are unreadable and puzzling like "Pages including reco...", just wiki categories apparently. Can filter for metro stations but can't filter them out.
It's barely working and have 1k downloads but already shows ads in my face.
I agree, dots should only be combined when they are actually overlapping by a significant amount. Otherwise you’re just hiding information in a frustrating way.
Looking things up in other urban areas does not yield this result for me. The grouping could be changed though. I can't click some Dots because there's on overlap with another dot.
Yeah, it's pretty useless in New Orleans, too. This is just not designed to cope with a place that is so interesting that you can have big stretches with a half-dozen wikinotable locations in every single block.
There's no lens of "good" or "interesting". Its just whether something is in wikipedia. This site is showing us that existence is wikipedia isn't that high of a bar to distinguish that something is actually interesting.
There are also just too many entries in dense areas. It's impossible to go through all of them for something that might be interesting for the reader specifically.
It would be nice if they could be categorized/color-coded by some type (nature/monument/establishment/etc...) on the map so people can sift through them more easily.
Idea is interesting, but zooming in every time you click on something is very unintuitive; if this is for "exploration" it should keep the zoom level while you click on things.
Also a direct link to Wikipedia would be nice instead of the full page preview (perhaps this was designed for mobile, I'm describing the desktop experience).
My husband built https://wikimap.wiki which shows every geotagged Wikipedia article on a map at once. It was actually quite complex to do this because of the large number of articles. The UI makes some compromises to try to keep it usable but it's a tough nut to crack with the highly variable density. It also has filtering by category and some features of that nature.
The major trick is that the article icons are a layer of prerendered tiles; the client can't handle that many objects. Clicking does a request to a geojson server backed by postgis to find what's in the region you clicked. I'm not sure that it's actually updating right now either, ingesting updates takes hours and is pretty brittle because of issues with the format of the dumps Wikipedia provides.
It mistakingly incorporates coordinates from other planets/satelites in our solar system. Seems a large fraction of those point nemo locations are meteorite impacts on nearby satelites.
Poking around a bit, I noticed that some of the geotagged articles are from other planets. For example, north of Alaska are a bunch of craters from Mercury. Makes me think that an interesting feature could be choosing which planet to render the map from :)
Unfortunately I don't think there's any structured way to determine which planet an article applies to. Broadly speaking, Wikipedia geotagging is inconsistent and the data quality is fairly poor. I think a lot of that is because it's surprisingly difficult to make a viewer like this, so few people have. That makes the data quality issues nonobvious.
Wikidata offers the promise of more structured data, but I know my husband experimented with it and decided not to use it. I think the problem was that mapping Wikidata objects to Wikipedia articles was too difficult (there is a structured way to do this but in practice very few articles have the annotation).
I'm still unsure what you're getting at. But what I suspect: if there is no local wikipedia version (e.g. the German wiki for Germany), then you possibly can't increase the number of data points, can't you? All depends on there being a Wikipedia in the first place.
I suppose I didn't (and still don't) understand why you singled out US and GB. Here's my take of the topic:
1. Wikipedia editions are not defined by region but by language, and the relationship between regions and languages is many-to-many. English is spoken (as a dominant language) in US/UK/CA/IE/AU/IN/... among others and German is spoken in DE/AT/CH/IT/... among others.
2. English is one of the language editions. The edition is special mainly in that it has the most diverse regional coverage.
3. All editions have an uneven regional coverage dependent of the speakers' distribution but also population density, literacy, social economics etc.
4. There is overlap between language editions so it's unclear whether given two their union would improve coverage and how.
5. Wikidata is the language-independent knowledge graph that includes the sum of the article metadata regarding all the Wikipedia editions (and more).
Now, a global map of Wikipedia articles in English is useful in its own right if you want to see what you can read in English. To improve the coverage, you would write articles about more topics in English.
However, if you wanted to see more dots on the map, you could base it on Wikidata to include all articles on all editions, or to include all Wikidata items even with no corresponding Wikipedia articles.
Whereas, if you wanted to see what you can read in German, you would need a map that includes the German articles and excludes the English articles.
And if you know multiple languages, you might want to see the union of those languages.
I start to think you may have in mind people who speak two languages: English and a regionally dominant language. If they wanted to see which articles they can read about the region, they could use a map of those two languages. If those two Wikipedia editions were significantly complementary, it would be a significant improvement in coverage for them.
Still, I'm unsure why to single out US/GB when there are other countries where English is the majority (or practically the only) language, there are other countries where the coverage in English is already fine, US/GB also have minority languages that could potentially improve their coverage etc.
let's take him at his word, "it's thin outside the US and GB." OK, hmmm, how do we get more global coverage? oh, of course, France would be fr.wiki and Germany would be de.wiki, that would really increase global coverage.
now you come in and say "but what about Canada, Australia, etc? there is no nz.wiki et al?" And then you have some ideas about how to do that, ideas which are not strictly "wikipedia" as we see in the headline idea.
Yup, that's it, thanks! My list of English-speaking countries just wasn't exhaustive and were the first I noticed with a higher density than the rest on first glance.
The language picker doesn't just change UI language, it changes which language Wikipedia is displayed.
There isn't really such thing as a "local Wikipedia" but of course coverage for a given country tends to be best on the Wikipedia in the language spoken there.
Not every language is supported (I think processing the fifteen Wikipedia dumps takes several days as is) but I believe the supported languages are the top 15 by number of articles.
Cool service! You could get rid of prerendering as well as handle clicks client-side if you switched to MapLibre and vector tiles (e.g. tippecanoe). On small zoom levels it doesn't really matter, but I think it would further improve the experience of zooming in.
Now, please make this into an app with driving directions and we can do use it while driving around. Drive to LA to SFO and see what attractions are along the way.
Curious where they're getting their data because I've never seen Toronto on an address line as: Toronto, Golden Horseshoe, Ontario, Canada. I think maybe it's potentially correct, but I've never seen that before in my life.
I once made a smartwatch interface for Wikipedia [1] and was intending on making it geolocate and tell you about interesting things you walk past.
However I stopped working an the project when (a) my project wouldn’t compile in the latest Android Studio without cutting and pasting every Java class, there was no auto-upgrade path that succeeded in compiling (b) Google EOL’d the search API I was using (c) every few months they wanted me to take some action to keep my app in the Play store and I got fed up with being asked to do unpaid work
This has been a feature in the Wikipedia mobile app for some time. It’s a real gem, I’ve found out some really interesting things about landmarks I pass every day.
This is awesome. Well implemented. I just learnt something new about the area I'm living in.
When I road tripped across US & CA the atlasabscura was my go-to for finding weird and wonderful places to explore. It had a great mix of historic, weird, artistic, irrelevant and timeless.
I’ve been househunting on and off for the last year or so. It was a bit wild to see one house that was in my price range¹ has a Wikipedia article.
⸻
1. The big issue was that the house was going to need a lot of work to be made livable. Add in that it was historically significant (designed by Frank Lloyd Wright) and it wasn’t going to be a simple matter to rehab it, especially on a recently divorced dad budget.
The Android app OsmAnd has a layer to display Wikipedia entries. I like the idea but like a few other people have commented here, some places there can be a lot of clutter from articles I'm not actually interested in. Maybe there could be a way to classify articles into broad categories and show a subset.
107 comments
[ 3.5 ms ] story [ 418 ms ] threadEdit: it's working now.
I currently live in a nondescript suburb of Los Angeles(Woodland Hills) and I’m always looking for interesting things to do in my area. This fits the bill exactly.
Also really liked the animation of the map when I typed in my area.
Cool idea and great execution.
The original blog post was quite negative, building something like this doesn't necessarily need a specific audience, the audience can come over time.
https://wikishootme.toolforge.org/
https://commons.wikimedia.org/wiki/Category:Bus_stops_in_Bud...
The one thing that would greatly streamline my own usage is a direct link to the Wikipedia page on the pin itself (without having to open the pin, wait for the modal, scroll to the Wikipedia link, then click through). I'm clicking around the local spots and opening the Wikipedia pages for the interesting locations in new tabs to read them all at once.
https://en.m.wikipedia.org/wiki/Special:Nearby
> Wikipedia cannot determine your location. Please try again with a better signal.
I'm on a desktop. Plugged into wired internet. My "signal" is fine.
No way of manually specifying a location is provided.
EDIT: Doesn't seem to work, the pages ignores what I put there and doesn't change behaviour.
EDIT: Same thing occurs in both Firefox and Chromium
> No way of manually specifying a location is provided.
... and that's exactly the issue.
Next steps on this kind of thing would be to classify the nearby items and then give them a score for how interesting they were.
For example, one of the items:
https://en.wikipedia.org/wiki/7th-8th_Street_&_Nicollet_stat...
This is a bus station. I have no idea why a bus station meets the qualifications to be included in Wikipedia in the first place, but it's definitely not an "interesting place nearby".
https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geograph...
If anyone wants to steal my million dollar startup idea, please credit my HN username in your IPO announcement: we need an app that integrates simple itinerary creation (airbnb/tripadvisor/google-sheets), itinerary management (tripit), restaurant selection (yelp), expense tracking (Splitwise), and this (ad-hoc location-based information of a vaguely “historical” or “informative” nature). Of course all with a sprinkling of LLM-magic on top for UX niceties.
So one app could connect a group over the course of a trip, helping them plan it both in advance and in the moment. Call it… _The Worldbook_.
It's barely working and have 1k downloads but already shows ads in my face.
I like the idea and will definitely visit again.
It would be nice if they could be categorized/color-coded by some type (nature/monument/establishment/etc...) on the map so people can sift through them more easily.
Also a direct link to Wikipedia would be nice instead of the full page preview (perhaps this was designed for mobile, I'm describing the desktop experience).
The major trick is that the article icons are a layer of prerendered tiles; the client can't handle that many objects. Clicking does a request to a geojson server backed by postgis to find what's in the region you clicked. I'm not sure that it's actually updating right now either, ingesting updates takes hours and is pretty brittle because of issues with the format of the dumps Wikipedia provides.
Poking around a bit, I noticed that some of the geotagged articles are from other planets. For example, north of Alaska are a bunch of craters from Mercury. Makes me think that an interesting feature could be choosing which planet to render the map from :)
Wikidata offers the promise of more structured data, but I know my husband experimented with it and decided not to use it. I think the problem was that mapping Wikidata objects to Wikipedia articles was too difficult (there is a structured way to do this but in practice very few articles have the annotation).
1. Wikipedia editions are not defined by region but by language, and the relationship between regions and languages is many-to-many. English is spoken (as a dominant language) in US/UK/CA/IE/AU/IN/... among others and German is spoken in DE/AT/CH/IT/... among others.
2. English is one of the language editions. The edition is special mainly in that it has the most diverse regional coverage.
3. All editions have an uneven regional coverage dependent of the speakers' distribution but also population density, literacy, social economics etc.
4. There is overlap between language editions so it's unclear whether given two their union would improve coverage and how.
5. Wikidata is the language-independent knowledge graph that includes the sum of the article metadata regarding all the Wikipedia editions (and more).
Now, a global map of Wikipedia articles in English is useful in its own right if you want to see what you can read in English. To improve the coverage, you would write articles about more topics in English.
However, if you wanted to see more dots on the map, you could base it on Wikidata to include all articles on all editions, or to include all Wikidata items even with no corresponding Wikipedia articles.
Whereas, if you wanted to see what you can read in German, you would need a map that includes the German articles and excludes the English articles.
And if you know multiple languages, you might want to see the union of those languages.
I start to think you may have in mind people who speak two languages: English and a regionally dominant language. If they wanted to see which articles they can read about the region, they could use a map of those two languages. If those two Wikipedia editions were significantly complementary, it would be a significant improvement in coverage for them.
Still, I'm unsure why to single out US/GB when there are other countries where English is the majority (or practically the only) language, there are other countries where the coverage in English is already fine, US/GB also have minority languages that could potentially improve their coverage etc.
let's take him at his word, "it's thin outside the US and GB." OK, hmmm, how do we get more global coverage? oh, of course, France would be fr.wiki and Germany would be de.wiki, that would really increase global coverage.
now you come in and say "but what about Canada, Australia, etc? there is no nz.wiki et al?" And then you have some ideas about how to do that, ideas which are not strictly "wikipedia" as we see in the headline idea.
> OK, hmmm, how do we get more global coverage?
Like I said, combine all the Wikipedia editions using Wikidata.
> oh, of course, France would be fr.wiki and Germany would be de.wiki
And of course, what language is e.g. Belgium (in your model)?
> And then you have some ideas about how to do that, ideas which are not strictly "wikipedia"
In this strict case, how do you remove duplicates (between the different language editions)?
There isn't really such thing as a "local Wikipedia" but of course coverage for a given country tends to be best on the Wikipedia in the language spoken there.
Not every language is supported (I think processing the fifteen Wikipedia dumps takes several days as is) but I believe the supported languages are the top 15 by number of articles.
Fun site, give him a high five for me
https://wginsberg.github.io/wikivoyage-map
However I stopped working an the project when (a) my project wouldn’t compile in the latest Android Studio without cutting and pasting every Java class, there was no auto-upgrade path that succeeded in compiling (b) Google EOL’d the search API I was using (c) every few months they wanted me to take some action to keep my app in the Play store and I got fed up with being asked to do unpaid work
[1] https://www.pcmag.com/news/attopedia-for-android-wear-puts-t...
One comment: I wish it didn't zoom in when I click a map pin. I prefer the map to stay in the same position.
I want to click around on the pins in focus. I’ll zoom in on the ones I find interesting.
When I road tripped across US & CA the atlasabscura was my go-to for finding weird and wonderful places to explore. It had a great mix of historic, weird, artistic, irrelevant and timeless.
⸻
1. The big issue was that the house was going to need a lot of work to be made livable. Add in that it was historically significant (designed by Frank Lloyd Wright) and it wasn’t going to be a simple matter to rehab it, especially on a recently divorced dad budget.