[HN Gopher] Large-Scale Generation of Transit Maps from OpenStre...
___________________________________________________________________
Large-Scale Generation of Transit Maps from OpenStreetMap Data
Author : chippy
Score : 240 points
Date : 2024-09-09 14:08 UTC (3 days ago)
(HTM) web link (www.tandfonline.com)
(TXT) w3m dump (www.tandfonline.com)
| alvarlagerlof wrote:
| This work is so impressive
| openrisk wrote:
| Amazing stuff at so many levels.
|
| Would live to hear more about the motivation for using RDF/SPARQL
| in the technology stack as these are frequently seen as arcane
| and here is a very intuitive use case.
| PaulHoule wrote:
| If you can get the math right you can frequently develop a very
| good system for representing data in RDF and writing SPARQL
| queries against it. A week of high-quality thinking can save
| you six months of time developing an alternate query system;
| the custom query system _might_ be better but it probably won
| 't be. It's easy to make something that is faster for
| specialized queries but unlikely you can build something that
| will let you write complex and versatile queries better than
| SPARQL.
|
| The key though is coining good identifiers, developing a good
| set of properties, and understanding how datatype properties
| work and using them well. It's very easy to develop a bad
| standard like Dublin Core that, unfortunately, perpetuates the
| bad stereotypes people have of the RDF world.
|
| The SPARQL spec is dense reading
|
| https://www.w3.org/TR/sparql12-query/
|
| but it's a tiny spec. The SQL spec on the other hand is broken
| up into numerous $200 documents and if you did look at them
| you'd find it's much much messier. If you felt SPARQL needed
| something extra it's a good base to work from to develop some
| kind of SPARQL++ and the same is true with the RDF model. (e.g.
| add something to every triple to record provenance, for
| instance)
|
| My two complaints with SPARQL are: (1) there are two official
| ways to represent ordered collections and a third unofficial
| one; if you are good at SPARQL you can write queries that can
| do the obvious things you want to do with ordered collections
| (like you'd see in JSON query languages like N1QL or AQL) but
| there ought to be built in functions that just do it, (2) you
| can write path queries like ?s
| (ex:motherOf|ex:fatherOf)+ ?o .
|
| which will match ?o being an ancestor of ?s. Sometimes you need
| to capture the matching path and SPARQL as it is doesn't
| provide a way to do that.
| spothedog1 wrote:
| Can you explain why you think Dublin Core is a bad standard?
| epsiro wrote:
| Online demo: https://loom.cs.uni-freiburg.de/global
| tda wrote:
| Really cool! Very impressed by the results thus far, but
| thrlere is also some room for improvement. Probably caused in
| parts by parsing, and in part by input data quality.
|
| - Taiwan has an insane rail network of a few hundred lines -
| half of the streamlines in Amsterdam are tram 7, apparently it
| takes you everywhere. - there seems to be an assumption all
| lines stop on all stations they pass - quite a few regional
| Train lines are committed in the Netherlands
|
| And finally I woul love a bus version too!
|
| Keep up the good work
| cabalamat wrote:
| This includes some railways but not others. For example the
| Edinburgh tram is missing.
| globular-toast wrote:
| The whole East Coast Mainline is missing!
| Doctor_Fegg wrote:
| And the code: https://github.com/ad-freiburg/loom
| eb0la wrote:
| Thanks for pointing out in the paper that lot of Spain and
| Italy is untagged !!
|
| It's interesting to see the first high-speed train line in
| spain (Madrid-Seville) doesn't appear. I'll see if I can fix
| that.
| zwirbl wrote:
| Really cool, but what is happening in Taiwan in the long
| distance rail map?
| qwertox wrote:
| Download link for the PDF:
| https://www.tandfonline.com/doi/pdf/10.1080/00087041.2024.23...
|
| Such a great piece of work, very interesting.
| remus wrote:
| What's novel/interesting about this? Speaking as an ignorant
| outsider, it seems like they're 'just' querying existing data and
| plotting it. Obviously this is a gross simplification, but I'd be
| really interested to hear what's hard about this problem.
| mattlutze wrote:
| From the introduction, Since the days of Harry
| Beck, transit maps have mostly been created manually by
| professional map designers (Garland Citation1994; Wu et al.
| Citation2020). The primary focus was on static maps, either
| distributed in print or electronically. These maps are
| typically schematic, and the classic octilinear design (network
| segment orientations are multiples of 45[?]) is still
| prevalent. In the late 1990s, the graph drawing community
| started to investigate the problem of drawing such maps
| automatically. The following questions were investigated: (1)
| How can graphs be drawn in an octilinear fashion? (2) Which
| hard criteria should a transit map fulfil? (3) Which soft
| criteria should be optimized? Several methods have since been
| proposed (see below). A set of soft and hard criteria, first
| described by Nollenburg (Citation2005), has since been
| generally accepted. The important sub-problem of finding an
| optimal line ordering of lines travelling through network
| segments has also been identified very early by Benkert et al.
| (Citation2006).
|
| It not trivial to automatically generate an optimally
| understandable octalinear transit map, and this group have
| combined bits of 30 years of research to do it in one go for
| every* bit of public transit on the planet.
|
| * _every bit that 's in OSM, I suppose_
| mistrial9 wrote:
| ok yes BUT .. a reason that transit maps were carefully
| composed is because people "who probably need assistance when
| using transit" plus "people who do not speak this human
| language" plus "people who depend on completeness and
| accuracy to a high degree" are all, at the same time, using
| one and only one map.
|
| hurrah for computer science BUT this is also graphic design,
| with human factors, and simultaneously authoritative data
| that does matter to many real people. Easy tag-on criticism
| is "who needs all transit maps worldwide at all times" ?
| Isn't it obviously more important to have reliable, accurate,
| readable maps for the people who are using the system heavily
| in that area, instead of stretching all of those qualities to
| get a toy-prize for armchair readers and the world cloud
| servers on the Internet? common sense plays a role in the
| guaging accolades here IMHO
| bigfudge wrote:
| This is really cool, but I wonder why the UK rail (commuter or
| long distance) network isn't shown very completely. There are
| _lots_ more trains around Birmingham or up north that don't get
| displayed. Even the network in the SE is very partial. Is this
| data really not in OSM?
| hobofan wrote:
| They discuss in the paper that those routes are less trivial to
| query. For that reason, and I guess to mimic the traditional
| local transit maps the online version only queries routes with
| the `route` key `light_rail`, `tram` or `subway`.
| widdershins wrote:
| This is really cool. I'm fairly impressed with the maps of the
| London underground, although there are some oddities in
| Octilinear mode. It's also missing quite a few Overground
| services.
|
| It's really nice to be able to switch seamlessly between a
| Geographic, Octilinear and Geo-Octilinear view of the maps,
| because each of them tells you something useful. I would use this
| if TFL added it to their maps app.
|
| https://loom.cs.uni-freiburg.de/global#subway-lightrail/octi...
| trains39472 wrote:
| It seems like it's missing most of Tokyo?
|
| Granted, Tokyo has a blended commuter / subway through-service
| system (eg, Fukutoshin-line trains continue into the Toyoko-
| line), but those trains don't seem to show up in either Rail or
| Subway views.
| shiroiushi wrote:
| It is missing most of Tokyo. All they did is look at the
| subways, specifically the Tokyo Metro system, and maybe a few
| other lines. The JR rail lines aren't on there, and no transit
| map of Tokyo is complete without those. The Yamanote line, in
| particular, is a crucial piece of Tokyo's transit
| infrastructure, and it's perfectly normal for people to transit
| between the underground Tokyo Metro and above-ground JR East
| lines.
|
| Most likely, they just left out the JR Rail and other lines
| because the map is way too complicated with them, or perhaps it
| broke their algorithm.
|
| They also didn't show the entire Tokyo metro area, which is
| much larger than this and includes Yokohama. It's
| understandable, though: the entire Tokyo metro area is enormous
| (though perhaps not compared to many American cities like
| Phoenix, if you just look at land area, but those cities have
| nowhere near the density of Tokyo), and a map of the entire
| thing is usually too complicated to bother with, so zoomed-in
| maps are more useful. This one is showing central Tokyo (the
| part encircled by the Yamanote line) and parts not too far from
| it.
| PaulHoule wrote:
| More generally if you try to do the whole world in one go you
| are not going to reach useful quality because every place has
| something unique about it in the transit network itself and
| also the map is curated by different people who do things
| differently. The map might look similar to an outsider but
| the particular codes, conventions and methods will be
| different.
|
| The answer for this, I think, is that either the OSM data
| (input) needs to adapt to fit what this system can read or
| patch rules and patch data can be applied to fix up the
| output.
|
| Either way it is a distributed project, people in Tokyo or
| Hannover or any place where it is wrong are the people who
| would know what is right so they should be engaged in the
| solution.
| YANNIC-G wrote:
| How Exciting project! How come there are no lines in Hanover, for
| example?
| mqus wrote:
| I was kinda expecting a reference to
| https://blog.transitapp.com/how-we-built-the-worlds-pretties...
| but I didn't find any while skimming it, even though the content
| seems to be very similar
| lqet wrote:
| A 2018 paper by the same authors [0] (referenced in this work)
| references an earlier blog post by the transitapp people on
| Medium, but the link is no longer working.
|
| > One approach that seems to use a model similar to ours was
| described by Anton Dubreau in a blog post
|
| [0] https://ad-publications.informatik.uni-
| freiburg.de/ACM_effic...
| geospatialover wrote:
| This is really excellent work! It does seem to be missing
| commuter train/rail systems in Canada, such as the GO Train
| system in Ontario.
| spothedog1 wrote:
| Very cool, I've been working on getting Qlever setup and using it
| as my main triple store. Was excited to see this hit my feed
___________________________________________________________________
(page generated 2024-09-12 23:01 UTC)