talk-ch

talk-ch@openstreetmap.ch

10 participants
2187 discussions

Stammtisch am 14. Juni um 18 Uhr
by Thomas Ineichen 15 Jun '11

15 Jun '11

Hallo zusammen, Auf Grund des Pfingstwochenendes und der Doodle-Umfrage findet der nächste Stammtisch erst am Dienstag, den 14. Juni statt: Datum: 14. Juni 2011 Zeit: ab 18 Uhr Ort: bei schlechtem Wetter: bei den Sofas zwischen bQm und Mensa, ETH Zürich http://www.openstreetmap.org/?lon=8.5467&lat=47.37598&zoom=18&mlon=8.5467&m… bei gutem Wetter: draussen auf der Terrasse (Rchtg. Polybahn) http://www.openstreetmap.org/?lon=8.5467&lat=47.37598&zoom=18&mlon=8.5462&m… Wie immer ist keine Anmeldung notwendig. Themen und weitere Infos (bald) auf: http://wiki.openstreetmap.org/wiki/DE:Switzerland:Zürich/OSM-Treffen Gruss, Thomas

3 2

Fwd: [Talk-de] Lizenzwechsel Phase 4 vermutlich ab 19.6.
by Simon Poole 14 Jun '11

14 Jun '11

War heute auch Thema am Stammtisch in Zürich: -------- Original-Nachricht -------- Betreff: [Talk-de] Lizenzwechsel Phase 4 vermutlich ab 19.6. Datum: Tue, 14 Jun 2011 23:03:06 +0200 Von: Frederik Ramm <frederik(a)remote.org> Antwort an: Openstreetmap allgemeines in Deutsch <talk-de(a)openstreetmap.org> An: Openstreetmap allgemeines in Deutsch <talk-de(a)openstreetmap.org> Hallo, vermutlich ab Sonntag 19.6. beginnt die Phase 4 im Lizenzwechsel, d.h. ab da koennen nur noch jene, die ODbL/CT zugestimmt haben, weiter editieren. Es wird diesmal versucht, den Fehler von letztem Mal zu vermeiden: Jemand, der nicht zugestimmt hat, soll durchaus weiter trac nutzen koennen oder Nachrichten verschicken ;) Die License Working Group schreibt allerdings (ich uebersetze von Mike Collinson): "Ich moechte betonen, dass es derzeit keine Notwendigkeit gibt, Daten aus unserer Datenbank zu entfernen, da die Lizenz immer noch CC-BY-SA ist. Ich glaube, wir koennen uns damit Zeit lassen, bis die ANzahl der Zustimmer so gross wie moeglich ist, oertliche Probleme, sofern moeglich, geloest sind und die Community einhellig findet, dass die Zeit reif ist. Die License Working Group nimmt weiterhin Kommentare entgegen." Bye Frederik -- Frederik Ramm ## eMail frederik(a)remote.org ## N49°00'09" E008°23'33" _______________________________________________ Talk-de mailing list Talk-de(a)openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de

1 0

Website openstreetmap.ch
by Marius Rieder 13 Jun '11

13 Jun '11

Hi Community, I plan to update the openstreetmap.ch in the near future. In my opinion the main focus of the website should be the map. For further information intend to link to openstreetmap.org where possible to avoid redundancy and keep maintenance costs low. As this are jest my 0.02$ i like to know the needs, wishes and ideas of the community. What do you/we need on openstreetmap.ch? - Marius -- ~o__O Marius Rieder O__o~ |vV| http://www.durchmesser.ch/ |vV| /] | <marius.rieder(a)durchmesser.ch> | [\ ---/|--|\--------[ Dance first. Think later. ]--------/|--|\---

10 23

Eisenbahn Geleise: Quellen?
by Blaaaaah 12 Jun '11

12 Jun '11

Wer auch immer im gesamten Grossraum Zürich sämtliche Geleise penibelst perfekt eingezeichnet hat: Fetten Respekt! Ich würde mich für die Quelle(n) interessieren... Sie scheint (scheinen) nicht die aktuellsten zu sein, ich habe bereits die eine oder andere Änderung eingepflegt. --RalpH_himself

1 0

FWD: [Announce] NOTICE: Scheduled Maintenance - 23rd June 2011]
by Sarah Hoffmann 09 Jun '11

09 Jun '11

FYI Kurzversion Deutsch: am 23.06.2011 ab 8:30 wird die API fuer ca. 12 Stunden nicht verfuegbar sein. version Francais: le 23 June 2011 au depart de 8:30 l'API ne sera pas disponible pendant ca. 12 heures. ----- Forwarded message from Grant Slater <openstreetmap(a)firefishy.com> ----- From: Grant Slater <openstreetmap(a)firefishy.com> Date: Thu, 9 Jun 2011 21:17:29 +0100 To: Talk Openstreetmap <talk(a)openstreetmap.org>, OSM Dev List <dev(a)openstreetmap.org>, announce(a)openstreetmap.org Subject: [Announce] NOTICE: Scheduled Maintenance - 23rd June 2011 Please copy this to local lists as appropriate. Thursday 7:30am (23rd June 2011 GMT/UTC+0) the API and map editing on www.openstreetmap.org will be unavailable. The maintenance period is expected to last for 12 hours. The following services will be unavailable during the maintenance period: API, editing features of www.openstreetmap.org and planet.openstreetmap.org including replication diffs. The wiki, mailing lists and help.openstreetmap.org will be unaffected. Technical: Some of the core servers are being re-located to another data-centre. Additional information will be posted to the following link closer to the time: http://wiki.openstreetmap.org/wiki/Servers/June_2011_Maintenance / Grant Part of the OSM sysadmin team. _______________________________________________ Announce mailing list Announce(a)openstreetmap.org http://lists.openstreetmap.org/listinfo/announce ----- End forwarded message -----

1 0

Didok check map
by Beni Buess 09 Jun '11

09 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi As Sarah requested :-) I made a map to help by checking stops after the Didok import. http://osm.xiala.net/didok-check/ If you have any suggestions on how to improve that, please let me know. At the moment the data is from geofabrik extract 8.6.2011. No automatic updates are implemented for now. There are still 12433 stops to check: http://osm.xiala.net/didok-check/statistics.html Good night Beni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN8AHIAAoJEOg6U/nfeJJMwccQAJj+DLRVJhtd+6i52l3wMIPZ vpPuK4uveId7czgqb4KxZnI3autXx9Dm0P9vHE+qlO4R59kRBkPGi5aF1IiAL9v7 D7Yy2v15MsbEqvCl7RYKWNm1/GQY5Lx8t6uWXg2jlEo1LU1qp4zga+IPiqHOWiAh S4kNl+ny2+0Baao66hSVnPc0DP/8A/UDmclJ5zcw+4WjTuszvbMFOxRiACYMIa1k dwWNEpRyBbC25+rMkQWNR+kEj5HaJkgUgVZoT4i58Yj68v2SJ7wE95KIxbr3q4Zt OLmMAXi+2SIbnqe8FMbVvFaieC/Hl6KSY57F+1Igww3S6vYKy/S7+NaA2jHZKY+z LzT4ejjqQqjVWQdlY2HDexKm5PT5Yj38RtvQ6ArkZrlMzDeUzK7OJgrUyULRitCy Rfo6S7oIQVeerI9T3YFsF2opPSwfXFym7UotjEal+IZ4Mrq/XEI0aygjJA7hy5d9 X6ggy3Iru2PjsblBCqfc3e5TAjYBBT/rFA2xNMpPeEob0uEf3RggA6sp6bqWNoNc j8xzCvoWFc4TcyCYV0vgYVhNSEH8xRkQTejS3HW5moAocAlt1Pvt8ZZ0W14UY5Df CAN4G60PsHiQYVXAch8Bdj41RWgd7CW6fTn0R0mqSkYyztOI8ufqV2RP4/ASrmzL gkd0ifNEmJ7OQenmRRw9 =C+2j -----END PGP SIGNATURE-----

4 4

Re: [talk-ch] Taginfo Switzerland
by Beni Buess 08 Jun '11

08 Jun '11

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

2 1

Rencontre Cartographe-Amateur
by Frédéric Benninger 07 Jun '11

07 Jun '11

Bonjour, Est ce qu'il y a des amateurs pour organiser prochainement une petite rencontre vaudoise ou romande? Salutations Frédéric

3 2

OSM-Stammtisch: Termin?
by Thomas Ineichen 07 Jun '11

07 Jun '11

Hallo zusammen, da der nächste 11. an einem Samstag ist, hier eine kleine Doodle-Umfrage: http://doodle.com/8ebkeh3ys4qkqhfp Die Abstimmung ist offen bis Donnerstag Nachmittag; Vorschläge für Treffpunkte bzw. Mapping-Aktivitäten werden gerne schon vorher hier entgegen genommen. :) Gruss, Thomas PS: Denkt daran, am 13. Juni ist Pfingstmontag.

1 0

Schweizer Grenzen (War: openstreetmap und qgis)
by Stefan Keller 06 Jun '11

06 Jun '11

Hallo Walter Am 5. Juni 2011 14:56 schrieb Walter Nordmann <walter.nordmann(a)web.de>: ... > Die OSM-Daten in QGIS als direkt als Layer zu verwenden, hat schon was. > Dann bräuchte ich hier nicht den Umweg über Shapes zu gehen: > > http://wnordmann.homeunix.com/images/stories/osm/forum/thomas1.png > > Die aktuellen Shapes UND POLY-Files mit und ohne Buffer dieser Länder gehen > demnächst wieder online. > > Gruss > Walter > > P.S. Die Schweizer sollten sich mal um ihre Boundaries kümmern; da sieht es > echt mau aus. Bei dieser mau-Schelte - was auch immer das heisst (:->) - solltest du aber uns Zürcher herausnehmen, da sehen die Grenzen doch wau(!) aus. LG, Stefan

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

talk-ch