[talk-ch] Taginfo Switzerland

Beni Buess beni at benel.net
Wed Jun 8 15:20:31 CEST 2011



----- Urspr√ľngliche Mail -----
> On Wed, Jun 08, 2011 at 12:58:17AM +0200, Beni Buess wrote:
> > I'm now working on something like a public transport API, which
> > would make it possible to get data consolidated by the rules of the
> > new public transport feature, but with respect to the situation,
> > that there
> > are thousands of stations with the "old" scheme. See some simple
> > stats on this [1].
> 
> Sorry to jump on this, but I hope 'consolidation' doesn't mean
> to mass retag things. I think this 'new' schema allows the 'old'
> tags to co-exist, so just leave them be.

I won't mass retag anything. I'm with you about the coexistence.
By consolidation i basically mean inheriting values from the relations, since the new schema introduces some kind of hierarchy. i'll do some logic to get the uic_ref and uic_name from a stop_area relation for every stop_position that doesn't have this information.  thats how some people are going to tag things to avoid redundancy in the osm db. but i need the uic_ref and uic_name to get the timetable information.

> 
> Personally, I prefer the 'old' schema because the 'new' proposal
> is about as simple and readable as a IEEE standard (or, if you
> prefer these things: the German tax laws). I mean: two nodes and
> one relation for a simple one way bus stop? Why? In 95% of cases
> the 'old' schema will do the job just fine and your map proves that.
one thing that is really cool about the new schema is this:
if the routes are properly defined with the right stop_positions (not the stop_areas), it will be possible to display very detailed timetable information since the timetable data could be filtered by the route information to display just the next departs for the clicked stop_position and not the stop_area, that would be cool and really unique. if there is a stop_area relation, it would still be possible to display all the departs from zurich hb for example. have you ever searched the right stop position for a certain bus line in bern or zurich?

> 
> > The API is not yet open for public use since I'm
> > still experimenting with the DB scheme best suited. I've tried the
> > scheme used by osm2pgsql, since it would then be easy to also render
> > the data with mapnik, but it is not really suited for complex querys
> > like all nodes/ways in the same stop_area as the given one. maybe i
> > have to get some data redundant in the DB, just to speed things up
> > and still be able to feed mapnik from it. But that would make the
> > upgrade process more complicated, any ideas?
> 
> Maybe you should have a look how I do the hiking map [1]. The
> philosophy is basically to derive specialised database schemata
> instead of using the one-size-fits-all version. This way you
> get tables that are suitable for both rendering and fast online
> queries.
> 
> I solved that by deriving table from a osmosis planet database.
> (There is the beginning of a framework [2] but really just the
> beginning.) The advantage is that it has full updating support.
> 
> Another library which has the same philosophy is imposm[3]. It
> imports specialised schemata directly from a osm-file. It might
> be a bit more mature, but there is no update-support.

i'm sure going to look into your framework. thank you.

> 
> > I'm going to try setting up a XAPI Switzerland using the new JXAPI
> > code, doesn't seem to be too hard (at least I hope so).
> 
> Cool.
> 
> > > The challenge is to
> > > maintain an up-to-date Swiss extract in the osmosis Postgresql DB.
> > Do you think that would be a problem, is the available software
> > (osmosis) not capable of doing this in a more or less automatic way
> > without to much fiddling? Any hints?
> 
> I would create an osmosis psql DB from the Swiss extract
> and then use the planetary minute update to keep it up-to-date.
> After each update the DB needs to be cropped to Swiss size. This
> step actually needs some thinking but it should be possible.
> (If you want to do it really well, you should write a special
> osmosis task that takes a polygon as input and crops the
> data already while updating the DB.)
have you ever cropped by polygon and not by bbox?
maybe it would also be possible to use postgres/postgis for this task. but then the data needs to get into the database first, which would not make it any faster i think.

auch gruss

beni



More information about the talk-ch mailing list