Live data from Hacker News

Large-Scale Generation of Transit Maps from OpenStreetMap Data

tandfonline.com

41–48 of 48 posts

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#41
post #3

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.

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…

Can you explain why you think Dublin Core is a bad standard?

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#43

Earlier quoted context omitted.

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…

Can you explain why you think Dublin Core is a bad standard?

(1) You can line it up side by side with the 1970 MARC standard

https://www.loc.gov/marc/

and, in terms of capabilities, MARC comes out way ahead. MARC is a standard for a university library, Dublin Core seems to be a standard that almost works for an elementary school library.

(2) Specifically, people who write a paper or a book will get prickly about the order that authors are listed in, but Dublin Core doesn't provide a good answer, particularly if you want to use authority records. I mean

   :Paper
       dcterms:creator "Alpher, Ralph" ;
       dcterms:creator "Bethe, Hans" ;
       dcterms:creator "Gamow, George " .
doesn't cut it because when you get the results back they could come back in any order. RDF has two different ways to represent ordered collections and they could have let you (required you to) write

    :Paper
       dcterms:creator ("Alpher, Ralph" "Bethe, Hans" "Gamow, George") .
which looks just like a Lisp list and internally is structured like one, but they didn't. In the XMP specification Larry Masinter specified that you do this

https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPS...

and boy there was a lot of good ideas in the XMP spec but Adobe wound up NERFing the implementation because Adobe was accused of throwing it's weight around too much. Sure you could write

   :Paper dcterms:creator "Ralph Alpher, Hans Bethe, George Gamow" .
but that won't work if you want to use URIs that point to authority records like the DC spec advises you to do. People hear RDF and think "Nothing to see here, move on" because of standards like Dublin Core that simultaneously seem inadequate and over complicated at the same time.

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#44

Earlier quoted context omitted.

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 l…

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 d…

Here's the official Tokyo Metro transit map: https://ontheworldmap.com/japan/city/tokyo/tokyo-subway-map....

It shows the subways, but also adds on the relevant JR rail lines and lines from other companies. Honestly, I don't see how this project could improve on this; the current map is already packed full of information.

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#45
post #6

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.

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 199…

Thanks, seems like the devil is in the details. It's a cool piece of work, very impressive browsing the generated maps.

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#46

Earlier quoted context omitted.

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 199…

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 authoritat…

I think you're describing one of the core motivations for these decades of research.

In most places still, changes to these maps need to go through lots of people process. This implies they're slow to update, and therefore often not entirely accurate or optimally understandable. For example, consider service works or temporary outtages.

The outcome of this research is not a toy-prize for armchair readers, but a generalized algorithmic approach to building necessary and important accessibility tools.

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#47

Earlier quoted context omitted.

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 authoritat…

I think you're describing one of the core motivations for these decades of research. In most places still, changes to these maps need to go through lots of people process. This implies they're slow to update, and therefore often not entirely accurate or optimally understandable. For example, consider service works or temporary outtages. The outcome of this research is not a toy-prize for armchair readers, but a gener…

as research it is interesting and gets wide attention, yes.

the reasoning above is a basis for rational discussion?

difficult to say in a diplomatic way on a computer science forum, that "replacing" human graphic design using algorithms does not get unlimited upvotes from me for real reasons

Re: Large-Scale Generation of Transit Maps from OpenStreetMap Data

#48
post #3

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.

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…

I'm just here to say that I fully agree with your comment. Hardcore RDF person myself but I wouldn't trade it for anything else. Once you master it it feels like cheating and/or magic sauce :)
Post reply on HN