Re: [OSM-talk] Zonal restrictions.
On Wed, 13 May 2009 17:08:51 +0200, Ben Laenen wrote: >> I really wouldn't recommend relations for specifying what things are >> inside an area. It's a waste of two entire dimensions our dataset >> happens to have. > > So while it may work for many zonal restrictions to use an area > (although even then there are still issues) you need another way as > well due to the bridge/tunnel issue, and that other mehod can only be > relations. Sorry to say that but if there are ways within the zone such as bridges and tunnels that are not affected, then this is not a zonal restriction at all. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Wed, 13 May 2009 15:54:36 +0100, Dave Stubbs wrote: >> The first thing I thought of when reading this is, to use a relation. >> 'Relations are not categories' applies to people making relations out of >> "all hotels" or "All hotels in London", doesn't really apply here. >> >> type=zone >> name=Dublin Centre >> maxspeed=20kph >> parking=no >> > > Where "zone" is a known geographic area? > A bounding way with tags like: > zone = restriction > maxspeed = 20kph > parking = no > > seems like the best way to do it to me if you don't want to just > replicate the tags on everything (and I can understand why you > wouldn't want to do that). > There's no software that'll pay attention to it atm, but then it's not > long ago that everything ignored route relations too. > > I really wouldn't recommend relations for specifying what things are > inside an area. It's a waste of two entire dimensions our dataset > happens to have. I completely agree here. A polygon is a simpler, easier to evaluate, to tag and much, much less error-prone way to do this compared to a relation that has all ways in that area as members. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
> Except it's not a geographic area, but rather a set of streets with that > restriction. If a bridge or tunnel without the restriction goes > over/under a street with the restriction you'll have a problem. In that case, that bridge can have differen speed limits set directly on the way. Just define that tags on individual ways override tags set in the zone and this will solve the issue. > So while it may work for many zonal restrictions to use an area > (although even then there are still issues) you need another way as > well due to the bridge/tunnel issue, and that other mehod can only be > relations. I've seen many zones with some limitations (mostly speed limit or some parking limitations), but such zones rarely contain any bridges or tunnels. If they do, they can be either tagged individually, or we can also make new relation that will contain the zone and roads that are NOT in the zone (relation containing those few exceptions like the bridges, tunnels, etc ... so they won't need individual tagging) Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] R: R: RFC: amenity=mortuary (and amenity=emergency_room)
> -Messaggio originale- > Da: talk-boun...@openstreetmap.org > [mailto:talk-boun...@openstreetmap.org]per conto di David Paleino > Inviato: mercoledì 13 maggio 2009 21.40 > A: talk@openstreetmap.org > Oggetto: Re: [OSM-talk] R: RFC: amenity=mortuary (and > amenity=emergency_room) > > > On Wed, 13 May 2009 18:16:59 +0200, Fabrizio Carrai wrote: > > > I agree for the "morgue" term. > > Well, ok. I'm not particularly in favour of one version over the other ;) > > > I would say something to key "amenity" an why I would prefer > the use of the > > key "landuse" > > Well, "landuse"?!.. it's not "land", it usually is a building... Maybe I'm > missing this, but maybe you forgot your motivations for "landuse"? "For areas of land used by people": maybe it too much generic and maybe the one I know it includes a building but has a wide garden all around. > > > I don't know in other launguages but in italian the most common > meaning for > > AMENITY is something nice, beautiful, pleasant... > > Eh già ;) > However, I'd really stick to "amenity": those are meant as > "facilities" (maybe > "facility=" would be better? But then we would need to change a > *lot* of tags > out there) In my opinion it would have been far more appropriate, but you are right, it is almost impossible to change. > > > attributes not related at all with "morgue" and few other > "amenity=..." like: > > > > - crematorium > > - dentist > > Uhm.. I'm studying dentistry.. wanna come? :p My one is already enough for me, thanks! ;-) > > > [..] > > > > Just for the sake of completeness there is also the (unusual) > translation in > > "comodita' " (commodity), that is the one that make more sense > in the OSM > > context. > > Also "comodità" in Italian has a different meaning from the > English term, I > believe. Corrections are always welcome, but in that case it is not important. Ciao! Fabrizio ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
This is an implementation of this for Live Journal: http://updates.sixapart.com/ Lets you connect to a TCP port and get live XML feed of all updates on Livejournal.. Has some cool features, such as discarding data from the stream when you can't keep up. /Erik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Wed, 2009-05-13 at 22:12 +0100, Thomas Wood wrote: > 2009/5/13 Ivo van den Maagdenberg : > > Hi Folks, > > > > This is some sort of quality of service question. Half of all the tiles on > > http://www.openstreetmap.org render as 'more OSM coming soon'. I want to > > know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable > > hardware) > > The tiles display this in the case of network troubles where the > server isn't reachable, they're also displayed if the tile hasn't yet > been rendered (and is present on the server's disk) and when it's not > possible to render on the fly. Otherwise, the tile is added to the > render queue and should be available at some point shortly in the > future. > > > Showing OSM to a friend that has not seen 'the Map' does not give a good > > impression this way. A solution is to implement some sort of double > > buffering where the old tiles are kept for display until the new one has > > properly rendered? Well, that's maybe impossible, but it would improve the > > responsiveness of the http://www.openstreetmap.org at the moment. > > I believe this is already the case. There is a cache of tiles which is used when the rendering can not keep up. The weekly planet import is running at the moment and I have temporarily turned of the re-rendering of tiles so you will only seeing tiles from the cache right now. I'm in the middle of making some updates to the server to migrate the cached tiles and rendering database to an external disk array which will speed things up quite a bit. All the old tiles should still be available, but the live rendering probably won't restart until some time tomorrow. If you really must see an image which has not been rendered, the export tab should still produce an image for you. Jon > > I am not 100% sure if this list is the most appropriate place to post and > > apolgise for hogging the wrong list with my concerns. > > > > Kind regards, > > Ivom > > > > > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > > > > > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
2009/5/13 Ivo van den Maagdenberg : > Hi Folks, > > This is some sort of quality of service question. Half of all the tiles on > http://www.openstreetmap.org render as 'more OSM coming soon'. I want to > know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable > hardware) The tiles display this in the case of network troubles where the server isn't reachable, they're also displayed if the tile hasn't yet been rendered (and is present on the server's disk) and when it's not possible to render on the fly. Otherwise, the tile is added to the render queue and should be available at some point shortly in the future. > Showing OSM to a friend that has not seen 'the Map' does not give a good > impression this way. A solution is to implement some sort of double > buffering where the old tiles are kept for display until the new one has > properly rendered? Well, that's maybe impossible, but it would improve the > responsiveness of the http://www.openstreetmap.org at the moment. I believe this is already the case. > I am not 100% sure if this list is the most appropriate place to post and > apolgise for hogging the wrong list with my concerns. > > Kind regards, > Ivom > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Corine Land Cover becomes a potential OSM data source...
at least in France. The Corine Land Cover (CLC) is refering to a european programme establishing a computerised inventory on land cover of the 27 EC member states and other European countries, at an original scale of 1: 100 000, using 44 classes of the 3-level Corine nomenclature. It is produced by the European Environment Agency (EEA) and its member countries and is based on the results of IMAGE2000, a satellite imaging programme undertaken jointly by the Joint Research Centre of the European Commision and the EEA . Until now, the terms of use did not allow commercial use unless the Agency has expressly granted the right to do so. This was stopping any possibility to use the land use data for OSM. But, beginning of 2009, french environment agency (IFEN) released the new version of the dataset of year 2006, called CLC2006 with a newer version of the terms of use which explicitely allow commercial use. After some discussions with the french authorities responsible for the programme in France, it has been clearly stated that the CLC2006 data for France can be imported into OSM. During this discussion, it appeared that the same way of opening the data access has been mentionned at the EEA committee. The ad hoc committee in Q1/2009 suggested the following proposal for the new terms of use: Use rights : EEA is promoting the widest possible use of all data produced during the project. All core land cover data (national and European CLC 2000-2006 changes, national and European CLC2006 and related metadata, high resolution built-up areas, including degree of soil sealing, 2006 and high resolution forest areas, 2006) will be made available free of charge via the web, for non-commercial as well as commercial uses. But until it is released at EEA level, only specific national programmes who officially adopted new terms of use compatible with the OSM licence could take this data as a potential source. For France, we are now looking how we will be able to import some of 44 classes. We also created a wiki page trying to translate the CLC nomenclature to OSM tags: http://wiki.openstreetmap.org/wiki/Corine_Land_Cover I would like to see your comments about this translation table but also more in general, about this data source. It is possible that some other states already used CLC data for OSM, in which case, we would appreciate if they could share their experience. regards, Pieren EEA web site for CLC2006: http://etc-lusi.eionet.europa.eu/CLC2006/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] more OSM coming soon
Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I am not 100% sure if this list is the most appropriate place to post and apolgise for hogging the wrong list with my concerns. Kind regards, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - (Geographical Places)
Hi all, this proposal [place=land/water + size_level=1 to 10] is now open for voting. Please vote at http://wiki.openstreetmap.org/wiki/Proposed_features/Geographical_Places I have made two changes to the original proposal: 1) "place_level" tag changed to "size_level" 2) Proposal extended to cover ways and areas. cheers, Ole ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] R: RFC: amenity=mortuary (and amenity=emergency_room)
On Wed, 13 May 2009 18:16:59 +0200, Fabrizio Carrai wrote: > I agree for the "morgue" term. Well, ok. I'm not particularly in favour of one version over the other ;) > I would say something to key "amenity" an why I would prefer the use of the > key "landuse" Well, "landuse"?!.. it's not "land", it usually is a building... Maybe I'm missing this, but maybe you forgot your motivations for "landuse"? > I don't know in other launguages but in italian the most common meaning for > AMENITY is something nice, beautiful, pleasant... Eh già ;) However, I'd really stick to "amenity": those are meant as "facilities" (maybe "facility=" would be better? But then we would need to change a *lot* of tags out there) > attributes not related at all with "morgue" and few other "amenity=..." like: > > - crematorium > - dentist Uhm.. I'm studying dentistry.. wanna come? :p > [..] > > Just for the sake of completeness there is also the (unusual) translation in > "comodita' " (commodity), that is the one that make more sense in the OSM > context. Also "comodità" in Italian has a different meaning from the English term, I believe. Ciao, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 57, Issue 39
> StreetView data would be awesome to have, since it would massivly > increase the amount of information we could add. Footpaths, speedlimits, > number of lanes, etc etc, Theses are things you can't get from aerial > imagery. > But surely you can get this from, say, actually going there, like most people do when they're out mapping?! If you are going to somewhere to collect GPX traces, and collect street names, you can collect any number of other pieces of information at the same time. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 1:48 PM, Matt Amos wrote: > its better to get this done without the main db and the rails_port > code diverging too much, so i'm looking for methods which are as > un-invasive as possible. I agree. Since it seems like a huge amount of work to augment the current infrastructure to support this, perhaps it would make more sense to follow what (I think) Frederik said: use the minutely diffs to create a pseudo-stream and see what sort of apps build up around it. What's left on making the diffs work? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 7:36 PM, Ian Dees wrote: > On Wed, May 13, 2009 at 1:33 PM, Matt Amos wrote: >> On Wed, May 13, 2009 at 7:30 PM, Ian Dees wrote: >> > On Wed, May 13, 2009 at 1:27 PM, Matt Amos wrote: >> >> sorry, i wasn't clear in my question: why triggers in particular, >> >> rather than one of the many other features that the DB provides for >> >> doing this? >> > >> > Mostly because it would allow us to use the same XML format that >> > everybody >> > already knows how to parse and because it's what I've worked with in my >> > limited PostgreSQL experience. >> >> why would it allow us to use the XML format? nothing in XML ever goes >> near the database. > > I meant that it would trigger some external executable that would build up > the XML, not that the database would do it. is the external executable called osmosis? >> > What other features were you thinking about? >> >> i was looking at snapshots and transaction IDs to isolate the updated >> rows in the history tables. > > I yield to your judgment on that. I haven't given myself enough time to > explore abusing the database app for such a thing. its better to get this done without the main db and the rails_port code diverging too much, so i'm looking for methods which are as un-invasive as possible. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 1:33 PM, Matt Amos wrote: > On Wed, May 13, 2009 at 7:30 PM, Ian Dees wrote: > > On Wed, May 13, 2009 at 1:27 PM, Matt Amos wrote: > >> sorry, i wasn't clear in my question: why triggers in particular, > >> rather than one of the many other features that the DB provides for > >> doing this? > > > > Mostly because it would allow us to use the same XML format that > everybody > > already knows how to parse and because it's what I've worked with in my > > limited PostgreSQL experience. > > why would it allow us to use the XML format? nothing in XML ever goes > near the database. > I meant that it would trigger some external executable that would build up the XML, not that the database would do it. > > What other features were you thinking about? > > i was looking at snapshots and transaction IDs to isolate the updated > rows in the history tables. I yield to your judgment on that. I haven't given myself enough time to explore abusing the database app for such a thing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 7:30 PM, Ian Dees wrote: > On Wed, May 13, 2009 at 1:27 PM, Matt Amos wrote: >> sorry, i wasn't clear in my question: why triggers in particular, >> rather than one of the many other features that the DB provides for >> doing this? > > Mostly because it would allow us to use the same XML format that everybody > already knows how to parse and because it's what I've worked with in my > limited PostgreSQL experience. why would it allow us to use the XML format? nothing in XML ever goes near the database. > What other features were you thinking about? i was looking at snapshots and transaction IDs to isolate the updated rows in the history tables. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 1:27 PM, Matt Amos wrote: > On Wed, May 13, 2009 at 7:13 PM, Ian Dees wrote: > > On Wed, May 13, 2009 at 1:09 PM, Matt Amos wrote: > >> > >> why via triggers? > > > > Because the database is the only aggregation point for the data. There > are > > many API servers (which would be the ideal spot for creating this data > > feed), but my initial thought was that it was quite cumbersome to try and > > aggregate the streams from the various API servers (along with > time-aligning > > them) when the DB server was already doing that for you. > > sorry, i wasn't clear in my question: why triggers in particular, > rather than one of the many other features that the DB provides for > doing this? > > Mostly because it would allow us to use the same XML format that everybody already knows how to parse and because it's what I've worked with in my limited PostgreSQL experience. What other features were you thinking about? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 6:30 PM, Frederik Ramm wrote: > Matt Amos wrote: >> >> i think if we can get the delay on the diffs down from 5 mins to under >> 2 mins then there's no reason why streaming can't be built on top of >> the diffs and be able to support all the things people want to do with >> streaming. > > What you are talking about is "simulated streaming" not real streaming. But > it would be a good start; establish some kind of simulated streaming that is > based on the diffs and costs us almost nothing (can be done by someone on > their own server off-site!), indeed! good, isn't it? ;-) > and when interesting applications spring from > this where everybody says "oh if these could only be real-time instead of 2 > minutes delayed" then one an still work on providing the same stream in a > live fashion. given that nothing is ever truly live - there will be a processing delay with any method - whats the real advantage in a 2 minute delay rather than a <1 minute delay? > By the way, if someone really wants to chase the edge of the database by > always downloading the latest minute diff, what is the suggested way to do > this? If he makes only one GET request per minute then the diff he is > looking for might already be 59 seconds delayed ;-) yep... but does another 59 seconds really matter? ;-) > can any of today's hip & > trendy messaging protocols be used to painlessly notify anyone who is > interested that "there's a new diff ready", instead of having over-eager > scripts poll the directory every 10 seconds? i guess it would be fairly easy to have a CGI script for the "next diff", i.e: after receiving the request it blocks until a new diff is ready and then returns that diff. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 7:13 PM, Ian Dees wrote: > On Wed, May 13, 2009 at 1:09 PM, Matt Amos wrote: >> >> why via triggers? > > Because the database is the only aggregation point for the data. There are > many API servers (which would be the ideal spot for creating this data > feed), but my initial thought was that it was quite cumbersome to try and > aggregate the streams from the various API servers (along with time-aligning > them) when the DB server was already doing that for you. sorry, i wasn't clear in my question: why triggers in particular, rather than one of the many other features that the DB provides for doing this? cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 1:09 PM, Matt Amos wrote: > why via triggers? > Because the database is the only aggregation point for the data. There are many API servers (which would be the ideal spot for creating this data feed), but my initial thought was that it was quite cumbersome to try and aggregate the streams from the various API servers (along with time-aligning them) when the DB server was already doing that for you. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 7:05 PM, Ian Dees wrote: > On Wed, May 13, 2009 at 12:18 PM, Matt Amos wrote: >> On Wed, May 13, 2009 at 5:15 PM, Tom Hughes wrote: >> > Ian Dees wrote: >> >> The whole argument I'm making is that after the initial >> >> implementation**, streaming the data is a lot less resource intensive >> >> than what we are currently doing. Perhaps I don't have the whole >> >> picture >> >> of what goes on in the backend, but at some point the changeset XML >> >> files are applied to the database. At this point, we already have the >> >> XML changeset that was created by the client. The stream would simply >> >> be >> >> mirroring that out to anyone listening over a compressed HTTP channel. >> > >> > You don't want Potlatch's changes then? or changes made by changing >> > individual objects rather than uploading diffs? >> >> +1 >> >> or even the diffs? any diff where someone creates an element has >> negative placeholder IDs, so extra work would have to be done altering >> the XML to match the IDs returned by the database. > > These are implementation details that would have to be hammered out after we > talk about design. > > You're right, I would prefer to have the database itself (via triggers) dump > to a file/network handle the data that's being written to it. This way, it > would be able to get everything (including Potlatch and diffs) as it was > created. why via triggers? cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 12:30 PM, Frederik Ramm wrote: > can any of today's > hip & trendy messaging protocols be used to painlessly notify anyone who > is interested that "there's a new diff ready", instead of having > over-eager scripts poll the directory every 10 seconds? The server would need to open up a socket and send out some sort of notification to whoever is listening whenever a new diff is ready. I imagine might even be an intermediate server application that listens to that notification, grabs the diff, and creates the pseudo-stream for others. This way, the pseudo-stream would be delayed by N+60 seconds, where N is the number of seconds it took to create/post/notify/download the diff. That's pretty darn good. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 12:18 PM, Matt Amos wrote: > On Wed, May 13, 2009 at 5:15 PM, Tom Hughes wrote: > > Ian Dees wrote: > >> The whole argument I'm making is that after the initial > >> implementation**, streaming the data is a lot less resource intensive > >> than what we are currently doing. Perhaps I don't have the whole picture > >> of what goes on in the backend, but at some point the changeset XML > >> files are applied to the database. At this point, we already have the > >> XML changeset that was created by the client. The stream would simply be > >> mirroring that out to anyone listening over a compressed HTTP channel. > > > > You don't want Potlatch's changes then? or changes made by changing > > individual objects rather than uploading diffs? > > +1 > > or even the diffs? any diff where someone creates an element has > negative placeholder IDs, so extra work would have to be done altering > the XML to match the IDs returned by the database. These are implementation details that would have to be hammered out after we talk about design. You're right, I would prefer to have the database itself (via triggers) dump to a file/network handle the data that's being written to it. This way, it would be able to get everything (including Potlatch and diffs) as it was created. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Hi, Matt Amos wrote: > i think if we can get the delay on the diffs down from 5 mins to under > 2 mins then there's no reason why streaming can't be built on top of > the diffs and be able to support all the things people want to do with > streaming. What you are talking about is "simulated streaming" not real streaming. But it would be a good start; establish some kind of simulated streaming that is based on the diffs and costs us almost nothing (can be done by someone on their own server off-site!), and when interesting applications spring from this where everybody says "oh if these could only be real-time instead of 2 minutes delayed" then one an still work on providing the same stream in a live fashion. By the way, if someone really wants to chase the edge of the database by always downloading the latest minute diff, what is the suggested way to do this? If he makes only one GET request per minute then the diff he is looking for might already be 59 seconds delayed ;-) can any of today's hip & trendy messaging protocols be used to painlessly notify anyone who is interested that "there's a new diff ready", instead of having over-eager scripts poll the directory every 10 seconds? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 5:15 PM, Tom Hughes wrote: > Ian Dees wrote: >> The whole argument I'm making is that after the initial >> implementation**, streaming the data is a lot less resource intensive >> than what we are currently doing. Perhaps I don't have the whole picture >> of what goes on in the backend, but at some point the changeset XML >> files are applied to the database. At this point, we already have the >> XML changeset that was created by the client. The stream would simply be >> mirroring that out to anyone listening over a compressed HTTP channel. > > You don't want Potlatch's changes then? or changes made by changing > individual objects rather than uploading diffs? +1 or even the diffs? any diff where someone creates an element has negative placeholder IDs, so extra work would have to be done altering the XML to match the IDs returned by the database. and the HTTP stream would contain many osmChange documents? that won't really work with any XML parser i know of... you'd need to pre-parse it into separate XML documents first. and how would you take these XML documents on the API servers and merge them into a consistent ordered stream, ensuring all data dependencies are satisfied? all of that in less work than than osmosis' diff queries? cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 4:40 PM, andrzej zaborowski wrote: > In a different mail you said: >> Ian Dees wrote: >>> OSM isn't about the geodata, it's about the data. That includes the fact >>> that it is in the geographic domain, but it also means that we can >>> manipulate it or store it however we want. >> >> You can. On your own infrastructure. > > Except you can't right now, the dumps don't provide enough information > to duplicate OSM database even on your own infrastructure. they don't *yet*. brett has been working on "full" diffs, i.e: diffs with all edits, whether they were later overridden or not. this would allow you to fully reproduce the whole database. see http://planet.openstreetmap.org/history/ for whats been done so far. Frederik said: > I fully agree that streaming is probably a niche thing, a nice-to-have > and not a must-have, and I have no problem if the idea is treated as a > small priority. But dismissing it just because your imagination is too > limited...? +1 i think if we can get the delay on the diffs down from 5 mins to under 2 mins then there's no reason why streaming can't be built on top of the diffs and be able to support all the things people want to do with streaming. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] R: RFC: amenity=mortuary (and amenity=emergency_room)
I agree for the "morgue" term. I would say something to key "amenity" an why I would prefer the use of the key "landuse" I don't know in other launguages but in italian the most common meaning for AMENITY is something nice, beautiful, pleasant...attributes not related at all with "morgue" and few other "amenity=..." like: - crematorium - dentist - emergency_phone - grave_yard - prison Just for the sake of completeness there is also the (unusual) translation in "comodita' " (commodity), that is the one that make more sense in the OSM context. Fabrizio > -Messaggio originale- > Da: talk-boun...@openstreetmap.org > [mailto:talk-boun...@openstreetmap.org]per conto di David Paleino > Inviato: martedi 12 maggio 2009 8.24 > A: talk@openstreetmap.org > Oggetto: [OSM-talk] RFC: amenity=mortuary (and amenity=emergency_room) > > > Hello, > I was mapping an hospital, and encountered two mortuaries/morgues. So I've > tagged them amenity=mortuary, building=yes, and proposed the new tag: > > http://wiki.openstreetmap.org/wiki/Proposed_features/Amenity:mortuary > > Any comment is highly appreciated, before I move it to vote :) > > Also, inside the same hospital, there is an ER, which is a > separate building in > my case. Thus I didn't find the combination amenity=hospital, > emergency=yes > (which insteads is applied to the whole hospital area) useful, > and I've tagged > it amenity=emergency_room. Before I draft a proposal for this > too, is there > anyone experienced with such a situation? > > Kindly, > David > > -- > . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino > : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ > `. `'` GPG: 1392B174 | http://snipr.com/qa_page >`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 > > Nessun virus nel messaggio in arrivo. > Controllato da AVG - www.avg.com > Versione: 8.5.325 / Database dei virus: 270.12.26/2110 - Data di > rilascio: 05/12/09 06:22:00 > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Frederik Ramm wrote: > I fully agree that streaming is probably a niche thing, a nice-to-have > and not a must-have, and I have no problem if the idea is treated as a > small priority. But dismissing it just because your imagination is too > limited...? It's fine for people to discuss it. What I object to is people wanting to implement it (or anything else) on the basis that somebody might, at some point, find it useful. If people have a concrete goal that they want to achieve then I'm all for discussing ways of achieving it but I don't see the point of creating technology just because we can. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Ian Dees wrote: > The whole argument I'm making is that after the initial > implementation**, streaming the data is a lot less resource intensive > than what we are currently doing. Perhaps I don't have the whole picture > of what goes on in the backend, but at some point the changeset XML > files are applied to the database. At this point, we already have the > XML changeset that was created by the client. The stream would simply be > mirroring that out to anyone listening over a compressed HTTP channel. You don't want Potlatch's changes then? or changes made by changing individual objects rather than uploading diffs? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Bernhard zwischenbrugger wrote: > To put OSM data live to xmpp ist very simple and I don't think it's > expensive. > > An easy way would be to post it to a xmpp groupchat: > > > geodata here > > > After login it's just a copy to a tcp socket port 5222. > Everybody who wants the data can log into the groupchat and gets all the > new data. > Jabber Servers can handle the load without problem (not sure about that > ) and maybe its possible to use an existing jabber server like > jabber.org, jabber.ru, Yes and then as soon your client disconnects for a second you've lost a ton of edits and you have no way to resync. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Jonathan Bennett schrieb: > andrzej zaborowski wrote: > > Cool visualisation tools don't have to comply with a) or b), they just > >> need to be cool :) >> > > So cool you're prepared to pay for the infrastructure to support it? > > > To put OSM data live to xmpp ist very simple and I don't think it's expensive. An easy way would be to post it to a xmpp groupchat: geodata here After login it's just a copy to a tcp socket port 5222. Everybody who wants the data can log into the groupchat and gets all the new data. Jabber Servers can handle the load without problem (not sure about that ) and maybe its possible to use an existing jabber server like jabber.org, jabber.ru, I would like to see that. It would be a perfect playground for me. Bernhard OSM Live (6 Minutes delay): http://datenkueche.com/osmlive/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 10:33 AM, Jonathan Bennett < openstreet...@jonno.cix.co.uk> wrote: > andrzej zaborowski wrote: > > Cool visualisation tools don't have to comply with a) or b), they just > > need to be cool :) > > So cool you're prepared to pay for the infrastructure to support it? > I think talking about hardware infrastructure is a little premature at this point, but yes, I would be happy to set up a server or 3 to send this streaming data around the world and take the load off of the db/api servers. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Hi, Jonathan Bennett wrote: > andrzej zaborowski wrote: >> You might be missing out on a cool visualisation tool though (maybe >> what Bernhard is trying doing is similar), but that's the only use >> case I can think of right now. > > How does that help anyone a) use the data, or b) improve the data? See > ITO's OSM Mapper if you want a *useful* visualisation tool. No live > stream needed there. Who are you to say what is useful and what isn't? The presentation from SOTM 2007 that I remember most vividly - the "wiggly maps" - was also the most useless. Every day someone says "let's not map because it is useless", and our mantra is "maybe it is just your limited imagination that makes this look useless". Why suddenly this very different attitude of yours? I fully agree that streaming is probably a niche thing, a nice-to-have and not a must-have, and I have no problem if the idea is treated as a small priority. But dismissing it just because your imagination is too limited...? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 10:28 AM, Jonathan Bennett < openstreet...@jonno.cix.co.uk> wrote: > Ian Dees wrote: > > Woah! Since when can OSM tell me what sort of applications I can and > > can't write with the open source data that OSM is providing**? > > You're not being told what to do with the data, but it's being suggested > to you that you can't have it in a particular, resource-intensive format > unless you can justify why you need it over and above an existing, less > resource hungry format, for an application that does something other > than go "Ooooh, shiny!" The whole argument I'm making is that after the initial implementation**, streaming the data is a lot less resource intensive than what we are currently doing. Perhaps I don't have the whole picture of what goes on in the backend, but at some point the changeset XML files are applied to the database. At this point, we already have the XML changeset that was created by the client. The stream would simply be mirroring that out to anyone listening over a compressed HTTP channel. Of course it could then by propogated to other servers if the bandwidth load was too great. One of the clients to this stream might be Osmosis, saving off chunks of data one minute wide and sending it to planet.openstreetmap.org, for example. ** ...and I've always said I would be willing to impelement this if we discussed it and decided there was a way to source the data in a technically feasible way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
We, the Romanian OSM team (as Norc is a Romanian based service), are in contact with the people from Norc since the launch of the project. They have given us permission to derive from their panoramas, and also they donated their GPS logs. We are waiting in the next few days to get a new set of tracks from their last surveys. More details here: http://www.mail-archive.com/talk@openstreetmap.org/msg13354.html --Ciprian On Wed, May 13, 2009 at 6:19 PM, John McKerrell wrote: > > On 13 May 2009, at 16:04, Joseph Reeves wrote: > > > How does the service provided by norc.ro compare with people's > > desires? > > > > http://www.norc.ro/ > > norc.ro looks similar to Google, which is nice, but I guess the > question is what license is the imagery available under? Also could I > submit my own imagery if I had any available? > > John > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
2009/5/13 Jonathan Bennett : > andrzej zaborowski wrote: > > Cool visualisation tools don't have to comply with a) or b), they just >> need to be cool :) > > So cool you're prepared to pay for the infrastructure to support it? I didn't say that. I said there *are* things you're missing out on. In a different mail you said: > Ian Dees wrote: >> OSM isn't about the geodata, it's about the data. That includes the fact >> that it is in the geographic domain, but it also means that we can >> manipulate it or store it however we want. > > You can. On your own infrastructure. Except you can't right now, the dumps don't provide enough information to duplicate OSM database even on your own infrastructure. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
andrzej zaborowski wrote: > Cool visualisation tools don't have to comply with a) or b), they just > need to be cool :) So cool you're prepared to pay for the infrastructure to support it? -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
2009/5/13 Jonathan Bennett : > andrzej zaborowski wrote: >> You might be missing out on a cool visualisation tool though (maybe >> what Bernhard is trying doing is similar), but that's the only use >> case I can think of right now. > > How does that help anyone a) use the data, or b) improve the data? See > ITO's OSM Mapper if you want a *useful* visualisation tool. No live > stream needed there. Cool visualisation tools don't have to comply with a) or b), they just need to be cool :) > >> What is a little worrying is that, as far as I see, there's no simple >> way to get a copy of the osm data (as in, everything that's in the >> database), even a week old -- because the planet file is only a >> "projection" of the data on a plane. > > I have no idea what a "projection of the data on a plane" is, unless > you're talking about an in-flight OSM movie. The planet file is > everything that's in the database, barring history info. Yup, barring history info. One of the dimensions is thrown away, this operation is called projection. I don't say I need to have a use case for the full database, but in any project it's only fair to give contributors a way to download the entire database with the data they created. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Ian Dees wrote: > Woah! Since when can OSM tell me what sort of applications I can and > can't write with the open source data that OSM is providing**? You're not being told what to do with the data, but it's being suggested to you that you can't have it in a particular, resource-intensive format unless you can justify why you need it over and above an existing, less resource hungry format, for an application that does something other than go "Ooooh, shiny!" > OSM isn't about the geodata, it's about the data. That includes the fact > that it is in the geographic domain, but it also means that we can > manipulate it or store it however we want. You can. On your own infrastructure. -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 10:11 AM, Jonathan Bennett < openstreet...@jonno.cix.co.uk> wrote: > Frederik Ramm wrote: > > But saying: "We don't intend to support this because we cannot think of > > an application that absolutely requires it", is quite un-OSM, is it not? > > Qualify "application" as "application which actually uses the geodata", > and it's not so far off the mark. We don't need a million tools that > just tell us where people are mapping. Woah! Since when can OSM tell me what sort of applications I can and can't write with the open source data that OSM is providing**? OSM isn't about the geodata, it's about the data. That includes the fact that it is in the geographic domain, but it also means that we can manipulate it or store it however we want. ** Provided it meets the requirements of the license that the data is released under. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On 13 May 2009, at 16:04, Joseph Reeves wrote: > How does the service provided by norc.ro compare with people's > desires? > > http://www.norc.ro/ norc.ro looks similar to Google, which is nice, but I guess the question is what license is the imagery available under? Also could I submit my own imagery if I had any available? John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
2009/5/13 Ian Dees : > 2009/5/13 Iván Sánchez Ortega >> >> As a wise man once said, "all problems in computer science can be solved >> by >> adding another indirection layer". >> >> If you really really want a stream, I'm positive it can be hacked with a >> couple of scripts and the minutely diffs. +1 > You have discovered one of my use-cases for the stream: the minutely diffs > should be generated from the stream by slicing the stream up into > minute-long segments and saving them to disk, not the other way around. why not? when its done the other way around its far, far simpler - just xml files on disk. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
andrzej zaborowski wrote: > You might be missing out on a cool visualisation tool though (maybe > what Bernhard is trying doing is similar), but that's the only use > case I can think of right now. How does that help anyone a) use the data, or b) improve the data? See ITO's OSM Mapper if you want a *useful* visualisation tool. No live stream needed there. > What is a little worrying is that, as far as I see, there's no simple > way to get a copy of the osm data (as in, everything that's in the > database), even a week old -- because the planet file is only a > "projection" of the data on a plane. I have no idea what a "projection of the data on a plane" is, unless you're talking about an in-flight OSM movie. The planet file is everything that's in the database, barring history info. Nothing more, nothing less. -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
2009/5/13 Jonathan Bennett : > Ian Dees wrote: >>> I don't think anybody has ever given a use case which requires such >>> a stream and can't work with the diffs. >> >> >> I agree, but the point is that minutely-diffs are a minute old. At some >> point in the future someone will want to see the data in real time as a >> stream. The only reason I can currently think of is because they don't >> want to have to deal with downloading the minutely diffs and would >> rather read a stream of XML messages, applying each one to their >> database somehow as they came in. > > The updates to the database aren't records of real-time, real-world > events; They're just mappers updating parts of the map. Anything which > analyses that, rather than the data itself as a whole is just > navel-gazing. It tells you something about the project, but not the > world it's mapping. > > You're not missing out on anything by having minute-old data. You might be missing out on a cool visualisation tool though (maybe what Bernhard is trying doing is similar), but that's the only use case I can think of right now. What is a little worrying is that, as far as I see, there's no simple way to get a copy of the osm data (as in, everything that's in the database), even a week old -- because the planet file is only a "projection" of the data on a plane. AFAIK Wikipedia manages to provide full database dumps so technically it should also be possible for OSM as we still (?) have less data and less traffic than WP. I'd think the streaming/download and upload (merging) of new data are two separable tasks that can be provided by separate servers with db replication between them. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Frederik Ramm wrote: > But saying: "We don't intend to support this because we cannot think of > an application that absolutely requires it", is quite un-OSM, is it not? Qualify "application" as "application which actually uses the geodata", and it's not so far off the mark. We don't need a million tools that just tell us where people are mapping. -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Wednesday 13 May 2009, Dave Stubbs wrote: > Where "zone" is a known geographic area? > A bounding way with tags like: > zone = restriction > maxspeed = 20kph > parking = no > > seems like the best way to do it to me if you don't want to just > replicate the tags on everything (and I can understand why you > wouldn't want to do that). Except it's not a geographic area, but rather a set of streets with that restriction. If a bridge or tunnel without the restriction goes over/under a street with the restriction you'll have a problem. > I really wouldn't recommend relations for specifying what things are > inside an area. It's a waste of two entire dimensions our dataset > happens to have. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
2009/5/13 Iván Sánchez Ortega > As a wise man once said, "all problems in computer science can be solved by > adding another indirection layer". > > If you really really want a stream, I'm positive it can be hacked with a > couple of scripts and the minutely diffs. You have discovered one of my use-cases for the stream: the minutely diffs should be generated from the stream by slicing the stream up into minute-long segments and saving them to disk, not the other way around. >From previous discussions with Brett, this is essentially what Osmosis is doing, but with the database as the input instead of the stream. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
How does the service provided by norc.ro compare with people's desires? http://www.norc.ro/ Cheers, Joseph 2009/5/13 Ian Dees : > On Wed, May 13, 2009 at 9:25 AM, John McKerrell wrote: >> >> On 13 May 2009, at 15:00, Rory McCann wrote: >>> >>> StreetView data would be awesome to have, since it would massivly >>> increase the amount of information we could add. Footpaths, speedlimits, >>> number of lanes, etc etc, Theses are things you can't get from aerial >>> imagery. >> >> I imagine that even if Google "made available" the StreetView imagery or >> data through an API the license would still be relatively restrictive. Look >> at the license for the maps released from Google Map Maker for instance >> (non-commercial use only). > > The engineers I have spoken with said that they want to release it > specifically so that organizations like OSM can use it. This would infer > that the license would be open enough for OSM. > >> >> As such I think that it's still likely that many of us would want to >> create our own alternative. > > Agreed. Beyond the legal issues it's still a very technically interesting > project. > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
El Miércoles, 13 de Mayo de 2009, Ian Dees escribió: > [...] the point is that minutely-diffs are a minute old. At some point in > the future someone will want to see the data in real time as a stream. If you can't wait *one* minute to see the data, you have a very acute case of OSMOCD, and you should see a psychiatrist. > The only reason I can currently think of is because they don't want > to have to deal with downloading the minutely diffs and would rather read a > stream of XML messages, applying each one to their database somehow as they > came in. As a wise man once said, "all problems in computer science can be solved by adding another indirection layer". If you really really want a stream, I'm positive it can be hacked with a couple of scripts and the minutely diffs. -- -- Iván Sánchez Ortega Un ordenador no es un televisor ni un microondas, es una herramienta compleja. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On Wed, May 13, 2009 at 9:25 AM, John McKerrell wrote: > > On 13 May 2009, at 15:00, Rory McCann wrote: > >> >> StreetView data would be awesome to have, since it would massivly >> increase the amount of information we could add. Footpaths, speedlimits, >> number of lanes, etc etc, Theses are things you can't get from aerial >> imagery. >> > > I imagine that even if Google "made available" the StreetView imagery or > data through an API the license would still be relatively restrictive. Look > at the license for the maps released from Google Map Maker for instance > (non-commercial use only). The engineers I have spoken with said that they want to release it specifically so that organizations like OSM can use it. This would infer that the license would be open enough for OSM. > As such I think that it's still likely that many of us would want to create > our own alternative. > Agreed. Beyond the legal issues it's still a very technically interesting project. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Hi, Peter Childs wrote: > The Problem is that you can't rebuild the map from a continuing > stream, This is the problem with Database Replication in general. True, but maybe the stream use cases don't require that? Maybe it is more important for an application to know in an instant where something is being edited, than having complete knowledge of what has been edited yesterday? I don't have a killer app in mind where I would say "this works with a stream and doesn't work with minute diffs". But I can think of a number of applications that would be cooler with a proper stream. I mean, just look at Bernhard's application: http://datenkueche.com/osmlive/ It looks very cool and you have the individual spots lighting up in something that looks like "real time" but then it is five minutes delayed and based on chunked diffs - meaning what you see is a fabricated replay of what has probably happened, and not "the real thing". Which diminshes the coolness, if only slightly. Now I'm not saying we should turn the database inside out to support fractionally more coolness. But saying: "We don't intend to support this because we cannot think of an application that absolutely requires it", is quite un-OSM, is it not? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
2009/5/13 Rory McCann : > On 30/04/09 13:17, Pieren wrote: >> On Wed, Apr 29, 2009 at 8:27 PM, Greg Troxel >>> and you define the relation to >>> say that all ways in some area of some type should be in the relation. >> >> You try to use relations to define a category but : >> >> http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories > > The first thing I thought of when reading this is, to use a relation. > 'Relations are not categories' applies to people making relations out of > "all hotels" or "All hotels in London", doesn't really apply here. > > type=zone > name=Dublin Centre > maxspeed=20kph > parking=no > Where "zone" is a known geographic area? A bounding way with tags like: zone = restriction maxspeed = 20kph parking = no seems like the best way to do it to me if you don't want to just replicate the tags on everything (and I can understand why you wouldn't want to do that). There's no software that'll pay attention to it atm, but then it's not long ago that everything ignored route relations too. I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
2009/5/13 Ian Dees : > Ok, this I'll agree on. My original post was just to talk about it... not > really to do it. But it sounds like we should take "baby" steps. Let's work > on the minutely diffs first and if some crazy person comes up with a good > use case for streaming, we can talk about it then. > The Problem is that you can't rebuild the map from a continuing stream, This is the problem with Database Replication in general. If you lose the stream for any reason you have to start again, which is a nightmare. Things that can be streamed like TV and Radio change over time and you don't need whats gone before. If you miss the beginning of a 24x7 News channel or a soap you can still work out whats going on about after a few minutes. With a Map you have not got a chance. Maps worry about quality. Streams don't I'm not quite sure how your stream would work. Theory Great, Practice don't work. Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On 13 May 2009, at 15:00, Rory McCann wrote: > > StreetView data would be awesome to have, since it would massivly > increase the amount of information we could add. Footpaths, > speedlimits, > number of lanes, etc etc, Theses are things you can't get from aerial > imagery. I imagine that even if Google "made available" the StreetView imagery or data through an API the license would still be relatively restrictive. Look at the license for the maps released from Google Map Maker for instance (non-commercial use only). As such I think that it's still likely that many of us would want to create our own alternative. Incidentally Ed Parsons has on numerous occasions and in various ways (I think twitter might be the only "in writing" way) said that it's probably ok to read road signs that can be seen from streetview imagery and things like that, so it may already be possible to do what we would like to be able to do for OSM. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Ian Dees wrote: >> I don't think anybody has ever given a use case which requires such >>a stream and can't work with the diffs. > > > I agree, but the point is that minutely-diffs are a minute old. At some > point in the future someone will want to see the data in real time as a > stream. The only reason I can currently think of is because they don't > want to have to deal with downloading the minutely diffs and would > rather read a stream of XML messages, applying each one to their > database somehow as they came in. The updates to the database aren't records of real-time, real-world events; They're just mappers updating parts of the map. Anything which analyses that, rather than the data itself as a whole is just navel-gazing. It tells you something about the project, but not the world it's mapping. You're not missing out on anything by having minute-old data. We're not recording how the world is changing, we're just making our map more accurate. As for wanting updates in a different format: Patches Welcome. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On 13/05/09 14:47, Ian Dees wrote: > This is different, though, as Google owns the StreetView data. They > license all other geographic data (street maps and aerial/satellite > images). Yes that's what I thought. As far as I know Yahoo licenced map data and bought the 'you can relicence it' option, whereas Google didn't. Hence as far as I know, Google can't legally let people use the aerial imagery like Yahoo can. StreetView data would be awesome to have, since it would massivly increase the amount of information we could add. Footpaths, speedlimits, number of lanes, etc etc, Theses are things you can't get from aerial imagery. signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 2:41 AM, Tom Hughes wrote: > Ian Dees wrote: > > I'd like to continue this part of the thread. As was discussed by >> Frederik, I think the end goal should be a real-time OSM stream of what's >> getting applied to the database. Doing that in a performant way is >> relatively difficult (which is why we're using Osmosis and minutely diffs >> right now), but I think we should be striving for having a realtime XML >> feed. >> > > I have to say I don't see any great reason to strive for it. Because it's there? Why are we striving to cover the globe with map data? :) > I don't think anybody has ever given a use case which requires such a > stream and can't work with the diffs. I agree, but the point is that minutely-diffs are a minute old. At some point in the future someone will want to see the data in real time as a stream. The only reason I can currently think of is because they don't want to have to deal with downloading the minutely diffs and would rather read a stream of XML messages, applying each one to their database somehow as they came in. Given that such a stream is uncacheable (and hence requires much higher > bandwidth outgoing from the core servers) The stream would be uncacheable, but could be repeated by others outside of the core server so that the bandwidth load was spread amongst the community. > and much more fragile than the diffs, it is not obvious that we should put > what would undoubtedly be a huge amount of effort into creating and > maintaining such a system rather than into doing other things. Ok, this I'll agree on. My original post was just to talk about it... not really to do it. But it sounds like we should take "baby" steps. Let's work on the minutely diffs first and if some crazy person comes up with a good use case for streaming, we can talk about it then. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-talk-ie] open street map - what's in it for you?
On 2 May 2009, at 14:10, Johnny Rose Carlsen wrote: > Nic Roets wrote: > >> On Fri, May 1, 2009 at 4:50 PM, Dermot McNally >> wrote: >> >>> "drove into a new housing estate" ... "yes but, what's in it for you?" >>> >>> Why does a painter paint? >>> >>> Why play football? >>> >>> Why give money to charity? >>> >>> Why volunteer to work with stroppy youths? (actually yeah, why?) >>> >>> Why walk up a mountain? >>> >>> >> The short answers to these questions are : Sex, sex, sex, sex, dunno >> and sex. > > Sex is also my reason #1 for doing OSM. skip to 02:35 or so in this from a couple of years ago: http://tinyurl.com/qwbt2c > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On Wed, May 13, 2009 at 8:38 AM, Joseph Reeves wrote: > For the same reason that they don't release any of their data? > This is different, though, as Google owns the StreetView data. They license all other geographic data (street maps and aerial/satellite images). There is significant interest in the engineering organization at Google to expose the data they own via an API of some sort. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On 30/04/09 13:17, Pieren wrote: > On Wed, Apr 29, 2009 at 8:27 PM, Greg Troxel >> and you define the relation to >> say that all ways in some area of some type should be in the relation. > > You try to use relations to define a category but : > > http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories The first thing I thought of when reading this is, to use a relation. 'Relations are not categories' applies to people making relations out of "all hotels" or "All hotels in London", doesn't really apply here. type=zone name=Dublin Centre maxspeed=20kph parking=no etc. Rory signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On Wed, May 13, 2009 at 8:31 AM, Rory McCann wrote: > Any idea why Google don't do this yet? > > I (and some others in the OSM community) have been working with some Google engineers on this for quite some time (1.5 yrs). There is significant interest in opening the data, but they are having problems getting the time to do it. I imagine the map team (those that are interested) is quite busy as Google Maps is one of the more popular products at Google. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
For the same reason that they don't release any of their data? 2009/5/13 Rory McCann : > On 01/05/09 15:05, Nick Whitelegg wrote: >> Google Street View got me thinking that it might be a good idea to explore >> the possibility of an open source street view database, which could be >> linked in with OSM. > > Course what would be awesome is if Google released all there timestamped > photos and GPS traces into a nice open licence. > > Any idea why Google don't do this yet? > > -- > Rory > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetView
On 01/05/09 15:05, Nick Whitelegg wrote: > Google Street View got me thinking that it might be a good idea to explore > the possibility of an open source street view database, which could be > linked in with OSM. Course what would be awesome is if Google released all there timestamped photos and GPS traces into a nice open licence. Any idea why Google don't do this yet? -- Rory signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-talk-ie] open street map - what's in it for you?
On 01/05/09 15:32, Ken Guest wrote: > A few days ago I drove into a new housing estate to add it to the map of the > locality. > > After explaining to a concerned resident what I was at (free-as-in-freedom > maps, no trap roads, accuracy etc) , I was asked a rather > Life-of-Brian-esque question: > > "yes but, what's in it for you?" > > Has anyone else been asked similar questions, and what was your response? > > > k. "It's like train spotting" is a decent answer for 95% of people. Train spotters are a bit kooky, but mostly harmless. Not a bad image to have. signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
On Wed, May 13, 2009 at 8:43 AM, Lennard wrote: > Matt Amos wrote: > >> these might be of interest: >> >> http://matt.sandbox.cloudmade.com/ > > Which would have been fine and dandy in the past, but somebody needs to > nudge that one into life again, /me thinks. yeah, sorry. its on my todo list ;-) cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Hi Maybe you like this: http://datenkueche.com/osmlive/ If I get nice feedback I will make it zoomable. Bernhard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Frederik Ramm wrote: > Tom Hughes wrote: >> It's a completely insane solution though. It we want to do it we >> should just do it properly in the database not fart around with stupid >> hacks in the rails code that break as soon as any updates are not done >> via rails. > > Assuming for a moment that the database was our bottleneck, something > that can be done by "farting around" on a number of easily scalable API > servers would of course compare favourably to burdening the > not-so-scalable database with triggers and extra write operations, would > it not? The fact that the servers are easily scalable is part of the problem as it means that any such logging system involves merging the actions of some 80 or so processes spread over 4 separate machines (at present). That either means some complicated and fragile locking scheme to control who is writing to the log at any given time or some scheme for merging a whole load of separate logs. > Now I don't know how often you manually modify database contents, but I > would think that any operation of a scale that would lead us to bypass > the rails API would also be very likely to blow apart anyone who listens > for edits downstream, so in my eyes there's not much to be gained by > streaming these "manual override" kinds of edits as well. I'm not thinking about manual modifications. I'm thinking about things like the gpx import that are no longer in rails. I think that is only likely to spread to include much of the API in the not too distant future. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Matt Amos wrote: > these might be of interest: > > http://matt.sandbox.cloudmade.com/ Which would have been fine and dandy in the past, but somebody needs to nudge that one into life again, /me thinks. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Ian Dees wrote: > I'd like to continue this part of the thread. As was discussed by > Frederik, I think the end goal should be a real-time OSM stream of > what's getting applied to the database. Doing that in a performant way > is relatively difficult (which is why we're using Osmosis and minutely > diffs right now), but I think we should be striving for having a > realtime XML feed. I have to say I don't see any great reason to strive for it. I don't think anybody has ever given a use case which requires such a stream and can't work with the diffs. Given that such a stream is uncacheable (and hence requires much higher bandwidth outgoing from the core servers) and much more fragile than the diffs, it is not obvious that we should put what would undoubtedly be a huge amount of effort into creating and maintaining such a system rather than into doing other things. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
