Re: [OSM-talk] Changed highway=*_link meaning?!
M∡rtin Koppenhoefer wrote: > highway=* > link=yes actually I like this, but it's not the first time it is proposed here, and I think you can hardly change tags used as often and for so long time as this. It would probably end up in a similar mess than path and footway. A number of the 'base' decisions would now make a lot more sense done a different way, but at the time there were very good reasons for choices then. With the amount of additional data now being handled, adding even more tags for some of the old basics while possible would just cause agro everywhere. Exactly as we now have in things like path. I don't know where the discussion on virtual tags got to? These are tags built from finer detail when using the data from a lower resolution. In this case of highway=x, link=yes would return the single tag highway=x_link and applications that do not need to bother with any other tags can carry on working happily with just the highway tag ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On 25 June 2010 16:10, Ed Avis wrote: > I think you misunderstand my proposal. I agree that is_in is redundant and > should not be added to the map. As you say, it can be derived from admin > boundaries. However, not every programmer might want to have to download all > the admin boundaries and work out what is in what. Conceivably, it might help > some applications if there were an option for the server to automatically add > is_in tags, generated from admin boundaries, when some map XML is downloaded. > That way the code to work it out only has to be written once. You are talking about pre-processing, that is taking the data and manipulating it and then doing something in another app with it, and this isn't something that has to be done with OSM directly, or even at all. > A road could appear as a dead end because of bad mapping - but then anything > else > on the map could also be bad mapping rather than reality. Anyway it's just an > example. I doubt you can make an assumption of a dead end, it might be a mapping mistake, or a way that hasn't been surveyed completely. > True, but if a way is tagged highway=steps or slope=yes, it's a pretty safe > bet > that going from layer 0 to 1 is uphill, and 1 to 0 is downhill. Even though > in > theory there is nothing to guarantee that. (And if elevation is tagged, > uphill > and downhill markers can be deduced for certain.) Most layer tags apply to bridges, not to steps because they don't go over the top of anything else. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Fri, 25 Jun 2010 06:10:18 + (UTC), Ed Avis wrote: > John Smith gmail.com> writes: > > >>and uphill/downhill for slopes (based on the layer of the endpoints). > > > >Layer has nothing to do with elevation, it only indicates which road > >goes over the other road there may not be any slope involved. > > True, but if a way is tagged highway=steps or slope=yes, it's a pretty safe > bet that going from layer 0 to 1 is uphill, and 1 to 0 is downhill. Even > though in theory there is nothing to guarantee that. Not only theory. Suppose you have a downhill highway=steps intersecting some other thing below. It's up to the mapper whether to tag this "thing" layer=-1 or to break the highway=steps and tag the middle segment layer=1. With your example, instead of the reality, you'd be ending up with an up followed by a down. layer=* is just really for the rendering, and shouldn't be used for anything else. > (And if elevation is tagged, uphill and downhill markers can be deduced for > certain.) Yes, that is the only safe tag. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 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] Changed highway=*_link meaning?!
John Smith gmail.com> writes: [proposal for 'virtual tags' generated automatically] >>As well as taking care of the different kinds of > link road, these could also provide 'is_in', 'leading_to' and 'dead_end' for > >dead_end can't be guessed at, it could be bad mapping, is_in is >redundant, you can use admin boundaries to derive this. I think you misunderstand my proposal. I agree that is_in is redundant and should not be added to the map. As you say, it can be derived from admin boundaries. However, not every programmer might want to have to download all the admin boundaries and work out what is in what. Conceivably, it might help some applications if there were an option for the server to automatically add is_in tags, generated from admin boundaries, when some map XML is downloaded. That way the code to work it out only has to be written once. A road could appear as a dead end because of bad mapping - but then anything else on the map could also be bad mapping rather than reality. Anyway it's just an example. >>and uphill/downhill for slopes (based on the layer of the endpoints). > >Layer has nothing to do with elevation, it only indicates which road >goes over the other road there may not be any slope involved. True, but if a way is tagged highway=steps or slope=yes, it's a pretty safe bet that going from layer 0 to 1 is uphill, and 1 to 0 is downhill. Even though in theory there is nothing to guarantee that. (And if elevation is tagged, uphill and downhill markers can be deduced for certain.) -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
2010/6/24 Roy Wallace : > highway=* > link=yes actually I like this, but it's not the first time it is proposed here, and I think you can hardly change tags used as often and for so long time as this. It would probably end up in a similar mess than path and footway. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Fri, Jun 25, 2010 at 4:21 AM, Lester Caine wrote: >> >> You could always have highway=link. > > But some links ARE motorway rules and some ARE trunk road so just saying link > does not work. highway=* link=yes ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cycle map not updating?
On Fri, 25 Jun 2010, Andy Allan wrote: > It starts coming down to questions of time and money, and I only have > a limited supply of both :-) Usually one has either time OR money, and never both at once ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 2:21 PM, Lester Caine wrote: > Anthony wrote: >> >> You could always have highway=link. >> > But some links ARE motorway rules and some ARE trunk road so just saying > link does not work. I guess, but now you're using a different definition of *_link. Not "tag-for-higher" nor "tag-for-lower", but "tag-based-on-the-rules". That's excellent if we can come up with some good definitions for what those rules are. > But IMO, it's not a big enough deal to bother changing. >> > There is a lot of good detail already mapped that does not need changing. > Just using as it was intended. Right now the definition of motorway_link is a link road between a motorway and another road. There's no mention of a requirement that the road be subject to "motorway rules". And whether or not the link road is connected to a motorway is something that is inherent in the nodes/ways themselves. So there's no detail which wouldn't be given by highway=link. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
On 25 June 2010 04:37, Richard Weait wrote: > I'm not sure I understand your question. Over time, the overhead increases, not just the amount of data. > You can import a bounding box or extract and have smaller tables. > > You can import without --slim, if you have the hardware for it, and I didn't mean without the slim option. > lose some large tables. But then you lose the ability to update > unless you do a re-import. That's my question, how to eliminate overhead in the database without re-importing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
On Thu, Jun 24, 2010 at 10:39 AM, John Smith wrote: > On 25 June 2010 00:28, Richard Weait wrote: >> overall disk use ~ 130 GB and growing about 2.5 GB/week at the moment. > > Is there a way to reduce this overhead without re-importing? I'm not sure I understand your question. You can import a bounding box or extract and have smaller tables. You can import without --slim, if you have the hardware for it, and lose some large tables. But then you lose the ability to update unless you do a re-import. Other alternatives? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cycle map not updating?
An alternative is to use Maperitive and render on the local PC. Its just a matter of using the right rules for rendering but you do need an .OSM file from the web unless you have a local copy. Cheerio John On 24 June 2010 12:53, Andy Allan wrote: > Yeah. Also, as Toby says, it's pretty much "totally overloaded", and > has been for the last few months. > > What's happened recently was that the updates broke for a few weeks, > and were restarted last Wednesday. The disk cache then filled up > completely on Friday, so there was only a small window for the tiles > to be re-rendered. Space was freed up on Monday, and then rendering > was stopped again on Wednesday for the next scheduled update. I > estimate it would take about 10-12 days to update all the tiles, and > there simply hasn't been very many days in the last week where the > system has been updating - and because it wasn't updating for three > weeks before that, some tiles are seriously out of date. They should > sort themselves out, over the next week or so. > > As for the new server that's being mentioned, that's being set up at > the moment. New host, new hardware, new software (mainly newer > versions of mapnik and osm2pgsql). Unfortunately it's not as fast as > I'd hoped, and I'm seriously concerned about whether it'll be able to > take the load! Running osm2pgsql in slim mode is soaking up much of > the hardware improvements. We'll see how it goes, but I'm confident > the whole thing is moving in the right direction. > > It starts coming down to questions of time and money, and I only have > a limited supply of both :-) > > Cheers, > Andy > > On Thu, Jun 24, 2010 at 4:54 PM, Shaun McDonald > wrote: > > Hi Gregory, > > Your a little out of date of the way that the cycle map is run. It uses > the > > live mapnk rendering, with no upload required. However it is still a > weekly > > update, and can take a week to fully update assuming that the disk > doesn't > > fill up first. > > Shaun > > On 24 Jun 2010, at 16:40, Gregory Williams wrote: > > > > Updates that I’ve made in the past week are now showing on zooms <= 12. > It’s > > not quite there for zooms > 12, but I suspect that that’s simply because > the > > tiles haven’t managed to upload to Andy’s web host yet from the machine > > where he carries out the main rendering. > > > > I do remember seeing Andy tweeting recently that there’d been an issue > with > > updates for a while (during an upgrade IIRC???), so perhaps that may > explain > > it. > > > > I usually notice that changes I’ve made prior to the Wednesday are > reflected > > at all zoom levels by the following Friday. > > > > From: talk-boun...@openstreetmap.org [mailto: > talk-boun...@openstreetmap.org] On > > Behalf Of Hillsman, Edward > > Sent: 24 June 2010 16:19 > > To: talk@openstreetmap.org > > Subject: [OSM-talk] cycle map not updating? > > > > Has the update frequency changed for OpenCycleMap? Some bike lanes added > in > > late May and early June still haven’t appeared yet. > > > > Ed Hillsman > > Senior Research Associate > > Center for Urban Transportation Research > > University of South Florida > > 4202 Fowler Ave., CUT100 > > Tampa, FL 33620-5375 > > 813-974-2977 (tel) > > 813-974-5168 (fax) > > hills...@cutr.usf.edu > > http://www.cutr.usf.edu > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > > > > > ___ > 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] Changed highway=*_link meaning?!
Anthony wrote: On Thu, Jun 24, 2010 at 1:14 PM, Lester Caine mailto:les...@lsces.co.uk>> wrote: Ed Avis wrote: Isn't this tagging redundant? If a link road leads from a primary to a secondary, or whatever, this can be seen by looking at the tags for the two roads it connects. In principle there is no need to duplicate the information. But how do you know that a way IS a slip from one road to another, and not just another road? You could always have highway=link. But some links ARE motorway rules and some ARE trunk road so just saying link does not work. But IMO, it's not a big enough deal to bother changing. There is a lot of good detail already mapped that does not need changing. Just using as it was intended. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 1:14 PM, Lester Caine wrote: > Ed Avis wrote: > >> Isn't this tagging redundant? If a link road leads from a primary to a >> secondary, or whatever, this can be seen by looking at the tags for the >> two >> roads it connects. In principle there is no need to duplicate the >> information. >> > > But how do you know that a way IS a slip from one road to another, and not > just another road? You could always have highway=link. But IMO, it's not a big enough deal to bother changing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On 25 June 2010 02:59, Ed Avis wrote: > download a section of map. As well as taking care of the different kinds of > link road, these could also provide 'is_in', 'leading_to' and 'dead_end' for dead_end can't be guessed at, it could be bad mapping, is_in is redundant, you can use admin boundaries to derive this. > streets, and uphill/downhill for slopes (based on the layer of the endpoints). Layer has nothing to do with elevation, it only indicates which road goes over the other road there may not be any slope involved. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
Ed Avis wrote: Isn't this tagging redundant? If a link road leads from a primary to a secondary, or whatever, this can be seen by looking at the tags for the two roads it connects. In principle there is no need to duplicate the information. But how do you know that a way IS a slip from one road to another, and not just another road? Tag it motorway when it goes to another motorway where is the division between motorway and slip road. It needs something to identify the situation on the ground! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
Isn't this tagging redundant? If a link road leads from a primary to a secondary, or whatever, this can be seen by looking at the tags for the two roads it connects. In principle there is no need to duplicate the information. In practice a renderer such as Mapnik may not allow you to write such complex rules, and doing so would complicate its code. As a blue-sky idea, we could have 'virtual tags' which are generated by the server automatically when you download a section of map. As well as taking care of the different kinds of link road, these could also provide 'is_in', 'leading_to' and 'dead_end' for streets, and uphill/downhill for slopes (based on the layer of the endpoints). Some simple query language would define such virtual tags and new ones could be added if an application finds them useful. -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cycle map not updating?
Yeah. Also, as Toby says, it's pretty much "totally overloaded", and has been for the last few months. What's happened recently was that the updates broke for a few weeks, and were restarted last Wednesday. The disk cache then filled up completely on Friday, so there was only a small window for the tiles to be re-rendered. Space was freed up on Monday, and then rendering was stopped again on Wednesday for the next scheduled update. I estimate it would take about 10-12 days to update all the tiles, and there simply hasn't been very many days in the last week where the system has been updating - and because it wasn't updating for three weeks before that, some tiles are seriously out of date. They should sort themselves out, over the next week or so. As for the new server that's being mentioned, that's being set up at the moment. New host, new hardware, new software (mainly newer versions of mapnik and osm2pgsql). Unfortunately it's not as fast as I'd hoped, and I'm seriously concerned about whether it'll be able to take the load! Running osm2pgsql in slim mode is soaking up much of the hardware improvements. We'll see how it goes, but I'm confident the whole thing is moving in the right direction. It starts coming down to questions of time and money, and I only have a limited supply of both :-) Cheers, Andy On Thu, Jun 24, 2010 at 4:54 PM, Shaun McDonald wrote: > Hi Gregory, > Your a little out of date of the way that the cycle map is run. It uses the > live mapnk rendering, with no upload required. However it is still a weekly > update, and can take a week to fully update assuming that the disk doesn't > fill up first. > Shaun > On 24 Jun 2010, at 16:40, Gregory Williams wrote: > > Updates that I’ve made in the past week are now showing on zooms <= 12. It’s > not quite there for zooms > 12, but I suspect that that’s simply because the > tiles haven’t managed to upload to Andy’s web host yet from the machine > where he carries out the main rendering. > > I do remember seeing Andy tweeting recently that there’d been an issue with > updates for a while (during an upgrade IIRC???), so perhaps that may explain > it. > > I usually notice that changes I’ve made prior to the Wednesday are reflected > at all zoom levels by the following Friday. > > From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] on > Behalf Of Hillsman, Edward > Sent: 24 June 2010 16:19 > To: t...@openstreetmap.org > Subject: [OSM-talk] cycle map not updating? > > Has the update frequency changed for OpenCycleMap? Some bike lanes added in > late May and early June still haven’t appeared yet. > > Ed Hillsman > Senior Research Associate > Center for Urban Transportation Research > University of South Florida > 4202 Fowler Ave., CUT100 > Tampa, FL 33620-5375 > 813-974-2977 (tel) > 813-974-5168 (fax) > hills...@cutr.usf.edu > http://www.cutr.usf.edu > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > > ___ > 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] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
From: Richard Weait Subject: Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet) To: talk@openstreetmap.org Date: Thursday, June 24, 2010, 4:28 PM On Thu, Jun 24, 2010 at 4:34 AM, Juan Lucas Domínguez Rubio wrote: > > Hello, thanks. > > Solved. I think the problem was that I was downloading the file to a remote disk (R: mapped to \\lanserver\data) > > Another question: after exporting the whole planet (recently) to Postgres, what is the size of the largest table created (which I presume will take up 80% of the whole DB)? based on my planet and minutely mapnik: 8 GB polygon 21 GB line 2 GB point 43 GB nodes 3 GB roads 50 GB ways 4 GB rels overall disk use ~ 130 GB and growing about 2.5 GB/week at the moment. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Hello, thanks. That's much more than what I expected. With a small example, I obtained a 1:3 ratio between the .osm format and the table size, so I estimated ~50 GB for the whole DB. Regards, Juan Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On 24 Jun 2010, at 5:24 , Richard Mann wrote: > On Thu, Jun 24, 2010 at 12:32 PM, Andy Allan wrote: >> the root of the discussion seems to have no basis in >> the tags, and seems entirely to be around rendering artefacts that you >> dislike. > > What purpose do the _link tags serve other than rendering? > then the rendering is completely broken and doesn't deserve a special tag. all the commercial maps render links much smaller and on lowest layer. > If there's a serious reason for tag-to-higher then we can add an > additional tag so people can record the status of what it links to > (and then we can render it any way we like). But I can't think of a > sensible reason for recording/using the higher status, except for > motorways, so it just seems like it's been copied from motorway_link > without thinking it through, is producing unintended results, and is > therefore an error that needs to be corrected. > from a rendering point of view this shouldn't matter at all. as said above rendering is ugly for *_link > If people have done that thinking through, and there's a genuine > reason for tag-to-higher for non-motorway roads, then I'd love to hear > about it. All the reaction so far seems to be a complaint about how I > did it, rather than the substance of the matter. > > Andy's made one of the few moderately serious points: it's confusing > to treat them differently to motorway links. Not exactly a clincher, > if it's wrong for other reasons. > consistency is more important to avoid confusion than an absolute statement. as others pointed out ramps to/from motorways and most likely on trunks are in the same jurisdiction and maintained by same agency as the motorway/trunk. So there is a clear evidence that *_link belongs to the higher road it connects to. > Richard Mann > > ___ > 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] cycle map not updating?
On 24/06/2010 16:57, Toby Murray wrote: Two days ago he tweeted that the new server was "nearly ready" so hopefully things will improve soon! And don't forget, if you think OpenCycleMap.org is great, you could always call in at the shop on the way out: http://shop.opencyclemap.org/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cycle map not updating?
Ooops. Thanks for correcting my Shaun. Unfortunately I've not had quite so much time to keep up-to-date on OSM happenings of late. From: Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] Sent: 24 June 2010 16:55 To: Gregory Williams Cc: 'Hillsman, Edward'; talk@openstreetmap.org Subject: Re: [OSM-talk] cycle map not updating? Hi Gregory, Your a little out of date of the way that the cycle map is run. It uses the live mapnk rendering, with no upload required. However it is still a weekly update, and can take a week to fully update assuming that the disk doesn't fill up first. Shaun On 24 Jun 2010, at 16:40, Gregory Williams wrote: Updates that I've made in the past week are now showing on zooms <= 12. It's not quite there for zooms > 12, but I suspect that that's simply because the tiles haven't managed to upload to Andy's web host yet from the machine where he carries out the main rendering. I do remember seeing Andy tweeting recently that there'd been an issue with updates for a while (during an upgrade IIRC???), so perhaps that may explain it. I usually notice that changes I've made prior to the Wednesday are reflected at all zoom levels by the following Friday. From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] On Behalf Of Hillsman, Edward Sent: 24 June 2010 16:19 To: talk@openstreetmap.org Subject: [OSM-talk] cycle map not updating? Has the update frequency changed for OpenCycleMap? Some bike lanes added in late May and early June still haven't appeared yet. Ed Hillsman Senior Research Associate Center for Urban Transportation Research University of South Florida 4202 Fowler Ave., CUT100 Tampa, FL 33620-5375 813-974-2977 (tel) 813-974-5168 (fax) hills...@cutr.usf.edu http://www.cutr.usf.edu/> http://www.cutr.usf.edu ___ 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] cycle map not updating?
Yeah I emailed Andy when I first started contributing to OSM because changes weren't showing up and some zoom levels in my area returned nothing but error tiles. He said the server was totally overloaded but that he was working on an upgrade. Since then updates have been hit and miss and the zoom levels that return error tiles have changed from time to time so I suspect he has been trying to do imports but some of them fail along the way. Two days ago he tweeted that the new server was "nearly ready" so hopefully things will improve soon! Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cycle map not updating?
Hi Gregory, Your a little out of date of the way that the cycle map is run. It uses the live mapnk rendering, with no upload required. However it is still a weekly update, and can take a week to fully update assuming that the disk doesn't fill up first. Shaun On 24 Jun 2010, at 16:40, Gregory Williams wrote: > Updates that I’ve made in the past week are now showing on zooms <= 12. It’s > not quite there for zooms > 12, but I suspect that that’s simply because the > tiles haven’t managed to upload to Andy’s web host yet from the machine where > he carries out the main rendering. > > I do remember seeing Andy tweeting recently that there’d been an issue with > updates for a while (during an upgrade IIRC???), so perhaps that may explain > it. > > I usually notice that changes I’ve made prior to the Wednesday are reflected > at all zoom levels by the following Friday. > > From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] > On Behalf Of Hillsman, Edward > Sent: 24 June 2010 16:19 > To: talk@openstreetmap.org > Subject: [OSM-talk] cycle map not updating? > > Has the update frequency changed for OpenCycleMap? Some bike lanes added in > late May and early June still haven’t appeared yet. > > Ed Hillsman > Senior Research Associate > Center for Urban Transportation Research > University of South Florida > 4202 Fowler Ave., CUT100 > Tampa, FL 33620-5375 > 813-974-2977 (tel) > 813-974-5168 (fax) > hills...@cutr.usf.edu > http://www.cutr.usf.edu > > ___ > 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] Good book on GIS concepts
El 23/06/2010 16:33, sko...@free.fr escribió: Would anyone recommend a good book on GIS/Geodesy/etc that could be used to understand the underlying concepts behind most GIS applications ? Try: http://wiki.osgeo.org/wiki/Library http://wiki.osgeo.org/wiki/Libros_de_SIG Best, -- Iván Sánchez Ortega ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cycle map not updating?
Updates that I've made in the past week are now showing on zooms <= 12. It's not quite there for zooms > 12, but I suspect that that's simply because the tiles haven't managed to upload to Andy's web host yet from the machine where he carries out the main rendering. I do remember seeing Andy tweeting recently that there'd been an issue with updates for a while (during an upgrade IIRC???), so perhaps that may explain it. I usually notice that changes I've made prior to the Wednesday are reflected at all zoom levels by the following Friday. From: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] On Behalf Of Hillsman, Edward Sent: 24 June 2010 16:19 To: talk@openstreetmap.org Subject: [OSM-talk] cycle map not updating? Has the update frequency changed for OpenCycleMap? Some bike lanes added in late May and early June still haven't appeared yet. Ed Hillsman Senior Research Associate Center for Urban Transportation Research University of South Florida 4202 Fowler Ave., CUT100 Tampa, FL 33620-5375 813-974-2977 (tel) 813-974-5168 (fax) hills...@cutr.usf.edu http://www.cutr.usf.edu/> http://www.cutr.usf.edu ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
2010/6/24 Andy Allan : > views or oppose them, but certainly the main point of this discussion > is that should we want to change it you can't just change the wiki and > declare it done! I completely agree to this and think it also applies to many other wiki edits. Sadly, as these edits create new confusion and problems especially for new users who are not yet familiar with a) the tag system and b) the fact that wiki pages sometimes get changed against the common sense of mapping. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Good book on GIS concepts
i think this can be a good start point http://linfiniti.com/dla/ video&pdf to introduce the GIS with qgis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Soviet military topographic maps
there is no mention of PD for these maps at mapstore.com. they are not even free of copyright from poehali.net free download doesn't mean PD Can I use the maps in my own project? You have the right to use maps for the purpose of familiarization for personal use. To use the maps or other materials in your project, you have to obtain our permission. Please use our email address i...@mapstor.com for communication. But please note: • All map images contain “poehali.net” imprint, which is our trademark • In order to avoid confusion, there should be clear distinction between your product/service and ours • We would greatly appreciate you citing us as a source of the images • We are always open to cross-marketing and/or link exchange. On 24 Jun 2010, at 3:22 , jamesmikedup...@googlemail.com wrote: > I am not saying that. I am saying that this is a topic for lawyers. > from what I learned about the discussion on wikipedia datapoints, it is uk > law that governs osm data. > mike > > 2010/6/24 Kirill Bestoujev > So you want to say that you do not care for those osm-users, which are > in Russia and which may have problems using osm with copyright data in > it? Did I get you right? > > K. > > 24 июня 2010 г. 13:56 пользователь jamesmikedup...@googlemail.com > написал: > > I think you should take this to the legal list. > > As far as I know, the copyright laws of england count for osm, not those of > > russia. > > mike > > > > 2010/6/24 Alexandr Zeinalov > >> > >> > We purchased them from this site : > >> > http://mapstor.com/ > >> > >> AFAIK this is not legal seller of maps, and poehali.org too. They both > >> hosted outside Russia. So this maps can't be reliable identified as public > >> domain maps. > >> > >> > Here the same data is available from a usaid sponsored project : > >> > http://www.bunkertrails.org/maps.php > >> > >> > > > > > > > > -- > > James Michael DuPont > > Member of Free Libre Open Source Software Kosova and Albania flossk.org > > flossal.org > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > > > > > > > -- > James Michael DuPont > Member of Free Libre Open Source Software Kosova and Albania flossk.org > flossal.org > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] cycle map not updating?
Has the update frequency changed for OpenCycleMap? Some bike lanes added in late May and early June still haven't appeared yet. Ed Hillsman Senior Research Associate Center for Urban Transportation Research University of South Florida 4202 Fowler Ave., CUT100 Tampa, FL 33620-5375 813-974-2977 (tel) 813-974-5168 (fax) hills...@cutr.usf.edu http://www.cutr.usf.eduhttp://www.cutr.usf.edu/> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 3:29 PM, Andy Allan wrote: > You need to explain, without referring to renderering *at any point in > the discussion* why your solution is both conceptually better than > what we have, and why your solution is worth all the hassle and > confusion that such a change would cause. So far, I see nothing > approaching the required level. There is no reason. Tag-to-lower is only of benefit to the renderer. Tag-to-higher is only for the benefit of the renderer. We'll have to go with a supplementary tag then. Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
On 25 June 2010 00:28, Richard Weait wrote: > overall disk use ~ 130 GB and growing about 2.5 GB/week at the moment. Is there a way to reduce this overhead without re-importing? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On 25 June 2010 00:22, David Paleino wrote: > And I still haven't read why you think this is better, apart from rendering > issues. > > As Andy said, the burden of demonstrating the goodness of a change is up to > who > wants to make that change. I've been following this thread and I've seen the back and forth, but the argument for/against routing seems pointless because *_link roads aren't usually very long so I can't see how it would effect anything. Same goes for rendering, regardless who wins this debate the other side will just end up tagging how they think things should be rendered. I can see a point for motorway_links, these are a specific sort of road, but the same thing does hold true for other roads, unless they were simply meant to imply oneway=yes, lanes=1 kind of thing, but I doubt they're currently rendered in that way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 3:09 PM, Richard Mann wrote: > On Thu, Jun 24, 2010 at 2:26 PM, Andy Allan wrote: >> On Thu, Jun 24, 2010 at 1:24 PM, Richard Mann >> wrote: >>> What purpose do the _link tags serve other than rendering? >> >> They can be used by routers to give more accurate descriptions... > That's a reason for calling them links, not a reason for tag-to-higher Which, if you look closely, was actually the question you asked me. >> http://osm.org/go/0...@c9as- > Could equally well be tertiary_link. Oh. I see. Good discussion, I'm totally convinced by your reasoning. >> As I say though, it's a well used and well established scheme, and we >> should be very wary of changing it just because of some edge cases >> where the rendering doesn't work correctly or where a particular >> junction seems bizarrely tagged. > > I don't think this is robust to non-geek rendering (which I think is > going to kick off fairly soon). People are going to start rendering > their towns, and tag-for-higher (and the normal renderer's response of > putting links under everything) just produces too much of a mess, too > often. People will find ways round it (like ignoring the wiki), but > it's better to solve the issue, and issue rendering advice that'll > actually work most of the time. Solving the issue would be to fix the renderers for the edge cases you are so interested it. > I'm more than happy for the wiki to say that tag-for-higher was the > norm for a long time and you need to be aware that it will remain in > the data for a long time. But tag-for-lower is better. Tag-for-higher *is still* the norm, and certainly isn't going to change just because there's a few artefacts here and there in some of the renderers. Nor is it going to change just because you want it to. You need to explain, without referring to renderering *at any point in the discussion* why your solution is both conceptually better than what we have, and why your solution is worth all the hassle and confusion that such a change would cause. So far, I see nothing approaching the required level. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
On Thu, Jun 24, 2010 at 4:34 AM, Juan Lucas Domínguez Rubio wrote: > > Hello, thanks. > > Solved. I think the problem was that I was downloading the file to a remote > disk (R: mapped to \\lanserver\data) > > Another question: after exporting the whole planet (recently) to Postgres, > what is the size of the largest table created (which I presume will take up > 80% of the whole DB)? based on my planet and minutely mapnik: 8 GB polygon 21 GB line 2 GB point 43 GB nodes 3 GB roads 50 GB ways 4 GB rels overall disk use ~ 130 GB and growing about 2.5 GB/week at the moment. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, 24 Jun 2010 15:09:11 +0100, Richard Mann wrote: > [..] But tag-for-lower is better. And I still haven't read why you think this is better, apart from rendering issues. As Andy said, the burden of demonstrating the goodness of a change is up to who wants to make that change. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 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] Changed highway=*_link meaning?!
Andy Allan wrote: They can be used by routers to give more accurate descriptions - e.g. since we don't (yet) indicate junction priorities, it can be helpful if you are on a *_link and going onto a * to announce it as "join the main carriageway". If it was e.g. just highway=trunk for both, the router wouldn't know you were on a slip road. Same for when you are approaching an exit, it's a nice hint to the router that you aren't following the main carriageway. And if you don't have the *_link, then there needs to be a replacement tag to provide that information! Although it should be possible to identify links between different road types, some will still be 'motorway' while others are slip roads and so join or leave. It is more difficult to decided what is going on where the slip roads are between one motorway and another, or motorway and a major trunk road. THESE needs to be specifically identified, and we had this discussion some years ago when the *_link tags were added! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
* Juan Lucas Domínguez Rubio [2010-06-24 01:34 -0700]: > Another question: after exporting the whole planet (recently) to > Postgres, what is the size of the largest table created (which I presume > will take up 80% of the whole DB)? I can't speak for the whole planet.osm file (so this might be useless), but I have (roughly) an extract of the United States. The largest table, planet_osm_ways, is 50 GB. The next-largest table, planet_osm_nodes, is 21 GB. After that is planet_osm_line at 8 GB. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Last night I met upon the stair A little man who wasn't there. He wasn't there again today. I think he's from the NSA! --- -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 2:26 PM, Andy Allan wrote: > On Thu, Jun 24, 2010 at 1:24 PM, Richard Mann > wrote: >> What purpose do the _link tags serve other than rendering? > > They can be used by routers to give more accurate descriptions... That's a reason for calling them links, not a reason for tag-to-higher > http://osm.org/go/0...@c9as- Could equally well be tertiary_link. OS would have them as tertiary_link (my Landranger still has it as a flat junction!) > As I say though, it's a well used and well established scheme, and we > should be very wary of changing it just because of some edge cases > where the rendering doesn't work correctly or where a particular > junction seems bizarrely tagged. I don't think this is robust to non-geek rendering (which I think is going to kick off fairly soon). People are going to start rendering their towns, and tag-for-higher (and the normal renderer's response of putting links under everything) just produces too much of a mess, too often. People will find ways round it (like ignoring the wiki), but it's better to solve the issue, and issue rendering advice that'll actually work most of the time. I'm more than happy for the wiki to say that tag-for-higher was the norm for a long time and you need to be aware that it will remain in the data for a long time. But tag-for-lower is better. Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Soviet military topographic maps
On 24 June 2010 23:00, jamesmikedup...@googlemail.com wrote: > Can I see some documentation on this theft? > Why dont you start with some dcma takedown notices for the people selling > them, and see what happens? You do realise DCMA is only for sites hosted in the US right? You seem to have bias here maybe because you, or someone you knew, has spent money obtaining them, in any case copyright is usually the default, not public domain and unless you know otherwise you should always assume the worst. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 1:24 PM, Richard Mann wrote: > On Thu, Jun 24, 2010 at 12:32 PM, Andy Allan wrote: >> the root of the discussion seems to have no basis in >> the tags, and seems entirely to be around rendering artefacts that you >> dislike. > > What purpose do the _link tags serve other than rendering? They can be used by routers to give more accurate descriptions - e.g. since we don't (yet) indicate junction priorities, it can be helpful if you are on a *_link and going onto a * to announce it as "join the main carriageway". If it was e.g. just highway=trunk for both, the router wouldn't know you were on a slip road. Same for when you are approaching an exit, it's a nice hint to the router that you aren't following the main carriageway. > If there's a serious reason for tag-to-higher then we can add an > additional tag so people can record the status of what it links to > (and then we can render it any way we like). But I can't think of a > sensible reason for recording/using the higher status, except for > motorways, so it just seems like it's been copied from motorway_link > without thinking it through, is producing unintended results, and is > therefore an error that needs to be corrected. There might be some edge cases, such as the one you previously linked to. But let's take this one near Cambridge: http://osm.org/go/0...@c9as- I think the slip roads on/off the trunk road dual carriageway are quite rightly tagged as trunk_link. It is very little different from the case of a normal motorway junction. If you had to choose whether those slip roads were part of the trunk road or of the secondary road crossing over it, I would think most people would go for trunk. And I suspect the facts on the ground would lean that way, when it comes to resurfacing, signage, speed limits, lane width, type of tarmac and so on, that the slip roads are more likely considered part of the trunk road. As I say though, it's a well used and well established scheme, and we should be very wary of changing it just because of some edge cases where the rendering doesn't work correctly or where a particular junction seems bizarrely tagged. > If people have done that thinking through, and there's a genuine > reason for tag-to-higher for non-motorway roads, then I'd love to hear > about it. All the reaction so far seems to be a complaint about how I > did it, rather than the substance of the matter. I think few people have expressed whether or not they support your views or oppose them, but certainly the main point of this discussion is that should we want to change it you can't just change the wiki and declare it done! > Andy's made one of the few moderately serious points: it's confusing > to treat them differently to motorway links. Not exactly a clincher, > if it's wrong for other reasons. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Soviet military topographic maps
On Thu, Jun 24, 2010 at 2:46 PM, Kirill Bestoujev wrote: > And by the way I am 100% sure that in UK stolen and later sold > copyright materials are not treated us public domain. > Can I see some documentation on this theft? Why dont you start with some dcma takedown notices for the people selling them, and see what happens? mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Soviet military topographic maps
This is only possible if those countries are nt members of international copyright treaties. Russia (and USSR) and UK - are members of those treaties. So same laws apply. And by the way I am 100% sure that in UK stolen and later sold copyright materials are not treated us public domain. K. 2010/6/24 John F. Eldredge : > When people in one country use servers in another country, the laws affecting > those users may not be the same as those affecting the servers themselves. > For example, some works are public-domain in Australia, but still in > copyright in the USA. So, it is legal for those works to be on the Gutenberg > Australia web site, without it being legal for users in the USA to download > those works. > > -- > John F. Eldredge -- j...@jfeldredge.com > "Reserve your right to think, for even to think wrongly is better than not to > think at all." -- Hypatia of Alexandria > > -Original Message- > From: "jamesmikedup...@googlemail.com" > Sender: talk-boun...@openstreetmap.org > Date: Thu, 24 Jun 2010 12:22:56 > To: Kirill Bestoujev > Cc: > Subject: Re: [OSM-talk] Licence of Soviet military topographic maps > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ > 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] Licence of Soviet military topographic maps
When people in one country use servers in another country, the laws affecting those users may not be the same as those affecting the servers themselves. For example, some works are public-domain in Australia, but still in copyright in the USA. So, it is legal for those works to be on the Gutenberg Australia web site, without it being legal for users in the USA to download those works. -- John F. Eldredge -- j...@jfeldredge.com "Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria -Original Message- From: "jamesmikedup...@googlemail.com" Sender: talk-boun...@openstreetmap.org Date: Thu, 24 Jun 2010 12:22:56 To: Kirill Bestoujev Cc: Subject: Re: [OSM-talk] Licence of Soviet military topographic maps ___ 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] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 12:32 PM, Andy Allan wrote: > the root of the discussion seems to have no basis in > the tags, and seems entirely to be around rendering artefacts that you > dislike. What purpose do the _link tags serve other than rendering? If there's a serious reason for tag-to-higher then we can add an additional tag so people can record the status of what it links to (and then we can render it any way we like). But I can't think of a sensible reason for recording/using the higher status, except for motorways, so it just seems like it's been copied from motorway_link without thinking it through, is producing unintended results, and is therefore an error that needs to be corrected. If people have done that thinking through, and there's a genuine reason for tag-to-higher for non-motorway roads, then I'd love to hear about it. All the reaction so far seems to be a complaint about how I did it, rather than the substance of the matter. Andy's made one of the few moderately serious points: it's confusing to treat them differently to motorway links. Not exactly a clincher, if it's wrong for other reasons. Richard Mann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
I believe this junction is tagged as per the wiki (which Andy kindly reverted to it's previous state). http://www.openstreetmap.org/?lat=51.73915&lon=-1.10389&zoom=15&layers=B000FTF Here's the same junction as per the cycle map layer: http://www.openstreetmap.org/?lat=51.73915&lon=-1.10389&zoom=15&layers=00B0FTF Clearly the tagging is just perfect and the renderers are perfect and the wiki is perfect, and it's all been wonderful for ever and nothing needs to be improved [/rant] Richard Mann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On Thu, Jun 24, 2010 at 10:55 AM, Richard Mann wrote: > Well that got more of a reaction than floating a discussion on the > tagging list, didn't it? The tagging list was set up so that the main > list wouldn't be bothered with such stuff. The tagging list was set up to save us all from the discussions surrounding tagging proposals and other minutiae of tagging discussions. Actions such as attempting to redefine the meaning of some of the most widely used tags in the entire project is, too put it mildly, outside the scope of that mailing list. > There's half a dozen unresolved items in trac, because the Mapnik > rules don't work, so you end up with gaps in casings where there > shouldn't be, and lower class roads rendered on top of higher class > link roads. It's significantly important to separate any complaints that you have with rendering from discussions on tagging. I have no interest in whether there are rendering artefacts such as gaps in casings in the current mapnik stylesheets. We have been using the given definitions of the tags since long before mapnik even existed! > So clearly not such a big issue that the talk list should be bothered with > it... There's a million random discussions in a dozen venues in the project. Simply because this particular discussion went almost unnoticed can't possibly be construed as a green-light to reverse the meaning of these tags. > So I look at the issue, consider the alternative rendering options > (links interwoven, links at bottom, motorway_links treated > differently), look at some commercial maps and see how they do it. And > come to the conclusion that the wiki is telling me to do something > wrong. So I change the wiki to give, in a succinct fashion, what I > think is the best advice for going forward, and one that's only likely > to improve matters. Clearly no-one's that much bothered, so it's a > small service to study the matter and write it up. Onwards and upwards > to better data and maps... You didn't really give "the best advice", you just decided that you knew better than everyone else, and made a change that affects 15,000 other mappers, hundreds of renderings and subprojects. A little more "due process" would be in order. > If there's a decent argument for tag-to-higher for roads between > trunk-tertiary, other than "we've always done it that way", let's hear > it. Preferably on the tagging list. The obligation on those who wish to change the meaning of such widely used tags is *entirely* on those who wish to make the change. You can't take an absence of discussion (given that many people have many more pressing issues to deal with) as consent for your change, nor demand that others need to justify *not* making such drastic changes. Especially since the root of the discussion seems to have no basis in the tags, and seems entirely to be around rendering artefacts that you dislike. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
Frederik Ramm writes: > I think that OSM as a whole - and this is not a legal issue - needs to > improve interoperability. What we're currently seeing is "import mania", > poeple trying to stuff every possible bit of information into OSM > because that's the easiest way for them to use it in conjunction with > OSM data. There is too much geodata in the world for this to be > sustainable - OSM must stick to things that mappers map. I agree. An EU-driven example about interoperability can be seen at http://www.paikkatietoikkuna.fi/web/en/map-window It is a pilot implemantation about what Inspire directive calls view services. Some rought OSM data from Geofabrik shapefiles are also included, on layers Transport networks - OpenStreetMap and Buildings - OpenStreetMap buildings. OSM data has a scale limit, zoom in enough and data appears but there are not many buildings outside the Helsinki district. GetFeatureInfo - the "i" tool works on these layers. Interoperability does not need to mean that everything that exists needs must be imported into OSM. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Licence of Soviet military topographic maps
But you should know that there are some copyright international agreements between many countries. Russian laws can't be used in England, and russian military secrets can't be protected by English laws. But it doesn't concern with copyright laws. Roscartographia is a copyright holder for soviet topo maps, so its rights may be protected by English laws. > I think you should take this to the legal list. > As far as I know, the copyright laws of england count for osm, not those > of > russia. > mike > > 2010/6/24 Alexandr Zeinalov > >> >> > We purchased them from this site : >> > http://mapstor.com/ >> >> AFAIK this is not legal seller of maps, and poehali.org too. They both >> hosted outside Russia. So this maps can't be reliable identified as >> public >> domain maps. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
On 24 June 2010 09:31, Frederik Ramm wrote: > Hi, > > Oliver (skobbler) wrote: > >> He shouldn't draw then into the database, as this mixes OSM data and his > >> own data. Why not just use a layer on top of the OSM data? > > > > One of the big advantages of OSM is that you the "drawing tools". An > option > > would be to create a blank database on top of the OSM data by using the > OSM > > tools. > > I think that OSM as a whole - and this is not a legal issue - needs to > improve interoperability. What we're currently seeing is "import mania", > poeple trying to stuff every possible bit of information into OSM > because that's the easiest way for them to use it in conjunction with > OSM data. There is too much geodata in the world for this to be > sustainable - OSM must stick to things that mappers map. > > I hope that it will become gradually easier to mix'n'match OSM with > other data at the rendering stage so that people will not feel compelled > to upload any rubbish to OSM just becasue they want to render it on a map. > > That will then also make it easier for those who wish to create produced > works from several databases, one of them being OSM, without tainting > their private data in the process. > I agree with this statement quite strongly. Once the rendering step is sorted, it should be then easy to mix the data without actually mixing private data and OSM data. Emilie Laffray ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Licence of Soviet military topographic maps
Well then assuming this we can even say that anyone not being physically in UK can use any copyrighted source (Google sat.) for instance to contribute to OSM, right? 24 июня 2010 г. 14:22 пользователь jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> написал: > I am not saying that. I am saying that this is a topic for lawyers. > from what I learned about the discussion on wikipedia datapoints, it is uk > law that governs osm data. > mike > > 2010/6/24 Kirill Bestoujev > > So you want to say that you do not care for those osm-users, which are >> in Russia and which may have problems using osm with copyright data in >> it? Did I get you right? >> >> K. >> >> -- Best regards, Eugene Iline ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Soviet military topographic maps
I am not saying that. I am saying that this is a topic for lawyers. from what I learned about the discussion on wikipedia datapoints, it is uk law that governs osm data. mike 2010/6/24 Kirill Bestoujev > So you want to say that you do not care for those osm-users, which are > in Russia and which may have problems using osm with copyright data in > it? Did I get you right? > > K. > > 24 июня 2010 г. 13:56 пользователь jamesmikedup...@googlemail.com > написал: > > I think you should take this to the legal list. > > As far as I know, the copyright laws of england count for osm, not those > of > > russia. > > mike > > > > 2010/6/24 Alexandr Zeinalov > >> > >> > We purchased them from this site : > >> > http://mapstor.com/ > >> > >> AFAIK this is not legal seller of maps, and poehali.org too. They both > >> hosted outside Russia. So this maps can't be reliable identified as > public > >> domain maps. > >> > >> > Here the same data is available from a usaid sponsored project : > >> > http://www.bunkertrails.org/maps.php > >> > >> > > > > > > > > -- > > James Michael DuPont > > Member of Free Libre Open Source Software Kosova and Albania flossk.org > > flossal.org > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > > > > -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Soviet military topographic maps
So you want to say that you do not care for those osm-users, which are in Russia and which may have problems using osm with copyright data in it? Did I get you right? K. 24 июня 2010 г. 13:56 пользователь jamesmikedup...@googlemail.com написал: > I think you should take this to the legal list. > As far as I know, the copyright laws of england count for osm, not those of > russia. > mike > > 2010/6/24 Alexandr Zeinalov >> >> > We purchased them from this site : >> > http://mapstor.com/ >> >> AFAIK this is not legal seller of maps, and poehali.org too. They both >> hosted outside Russia. So this maps can't be reliable identified as public >> domain maps. >> >> > Here the same data is available from a usaid sponsored project : >> > http://www.bunkertrails.org/maps.php >> >> > > > > -- > James Michael DuPont > Member of Free Libre Open Source Software Kosova and Albania flossk.org > flossal.org > > ___ > 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] Changed highway=*_link meaning?!
Well that got more of a reaction than floating a discussion on the tagging list, didn't it? The tagging list was set up so that the main list wouldn't be bothered with such stuff. There was no debate on the wiki, except a brief comment that presumably resulted in the tag-to-higher approach (from chriscf...), and another old comment that said the opposite. There's half a dozen unresolved items in trac, because the Mapnik rules don't work, so you end up with gaps in casings where there shouldn't be, and lower class roads rendered on top of higher class link roads. So clearly not such a big issue that the talk list should be bothered with it... So I look at the issue, consider the alternative rendering options (links interwoven, links at bottom, motorway_links treated differently), look at some commercial maps and see how they do it. And come to the conclusion that the wiki is telling me to do something wrong. So I change the wiki to give, in a succinct fashion, what I think is the best advice for going forward, and one that's only likely to improve matters. Clearly no-one's that much bothered, so it's a small service to study the matter and write it up. Onwards and upwards to better data and maps... Fortunately I have a thick hide. If there's a decent argument for tag-to-higher for roads between trunk-tertiary, other than "we've always done it that way", let's hear it. Preferably on the tagging list. Richard Mann On Wed, Jun 23, 2010 at 3:35 PM, Andy Allan wrote: > On Wed, Jun 23, 2010 at 2:16 PM, James Livingston > wrote: > >> You could argue that it's wikifiddling in an attempt to influence how people >> map, or that it's documenting how a lot of people already map. It's all a >> matter of perspective. > > If it was "documenting how a lot of people map" then it would say > there were two ways of doing it. This is clearly not the case, since > it was just arbitrarily changed. It's not a "matter of perspective". > >> I, and from what I see in use where I live quite a few other too, have >> always used xxx_link tags to join a highway=xxx with a higher one, because >> we think what was documented on the wiki (xxx_link joins highway=xxx with a >> lower one) is silly. > > So you're saying there's two ways to do it. One has been established > since forever, and is what almost everyone does (*_link is the higher > of the two joined roads). The other way, which a small number of > people use specifically because they don't like how the main method > renders, is complex and completely daft (link is the lower of the two > joined roads, except for motorway links, which are higher, and trunk > links, which are only permitted between two roads of the same level). > Right. > > I'd advise you started tagging using a more sensible, well established > scheme. And to realise that if you want to change the scheme, that's > an entirely different thing that can't be accomplished by changing the > wiki and then claiming it's valid. > > Cheers, > Andy > > ___ > 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] Licence of Soviet military topographic maps
I think you should take this to the legal list. As far as I know, the copyright laws of england count for osm, not those of russia. mike 2010/6/24 Alexandr Zeinalov > > > We purchased them from this site : > > http://mapstor.com/ > > AFAIK this is not legal seller of maps, and poehali.org too. They both > hosted outside Russia. So this maps can't be reliable identified as public > domain maps. > > > Here the same data is available from a usaid sponsored project : > > http://www.bunkertrails.org/maps.php > > > -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
Jukka Rahkonen wrote: > Users must just take care that they do not edit cable lines according to > what they see on the OSM map, otherwise all of the cable network data > will be considered to be derived from OSM data and thus fall under odbl. Very very broadly yes, but actually at that point (whichever licence you're using) you get into all the hoo-hah of defining "substantial". Realigning one cable along one straight OSM road is unlikely to be a substantial derivative, and therefore won't trigger share-alike. Realigning a massive network along every single road is, and will. It's all fun and games until someone gets sued. :) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Share-A-Like-non-Verifiability-because-they-are-not-publicly-accessable-tp5212191p5217021.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Licence of Soviet military topographic maps
> We purchased them from this site : > http://mapstor.com/ AFAIK this is not legal seller of maps, and poehali.org too. They both hosted outside Russia. So this maps can't be reliable identified as public domain maps. > Here the same data is available from a usaid sponsored project : > http://www.bunkertrails.org/maps.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
>What we're currently seeing is "import mania", >poeple trying to stuff every possible bit of information into OSM >because that's the easiest way for them to use it in conjunction with >OSM data. There is too much geodata in the world for this to be >sustainable - OSM must stick to things that mappers map. I fully agree. However, taking this thought then the current license is counterproductive in a way - unless you solve the problem with your mentioned "interoperability". Regards, Oliver -- View this message in context: http://gis.638310.n2.nabble.com/Share-A-Like-non-Verifiability-because-they-are-not-publicly-accessable-tp5212191p5217007.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
Richard Fairhurst writes: > Jukka Rahkonen wrote: > > Andy Allan writes: > >> If they have geographic data that we don't have, and they mix it > >> with OSM data, then the whole point is that we end up with access > >> to their geographic data. > > [...] > > You are obviously reading section 4.5 in a different way that I do. > > [...] > > For me it looks like business users can feel safe with their data if they > > do not make derivative databases, for example by enhancing their > > own data by taking tags from OSM database. Drawing their own data > > on top of OSM basemap is OK, isn't it? > > Which fits in exactly with what Andy said. > > The key word is "mix". Ok, I missed the meaning of "mix". Thus our advice for Oliver about the cable network is not to mix the private data with OSM data inside his own copy of OSM database. It will be OK to render OSM basemap tiles and use for example a separate WFS-T service [1] for showing and editing the cable network vectors. Users must just take care that they do not edit cable lines according to what they see on the OSM map, otherwise all of the cable network data will be considered to be derived from OSM data and thus fall under odbl. [1] Openlayers example combining tiles and WFS-T http://dev.openlayers.org/releases/OpenLayers-2.9.1/examples/ wfs-protocol-transactions.html -Jukka- > > cheers > Richard ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
On 06/24/2010 10:07 AM, Jukka Rahkonen wrote: > > For me it looks like business users can feel safe with their data if they do > not > make derivative databases, for example by enhancing their own data by taking > tags from OSM database. If enhancing means incorporating the data into a single database, they are producing a derivative. "Business users" are not special in this. > Drawing their own data on top of OSM basemap is OK, > isn't it? This is considered to be different from combining the data in a single database. (IANAL, TINLA.) - Rob. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
Jukka Rahkonen wrote: > Andy Allan writes: >> If they have geographic data that we don't have, and they mix it >> with OSM data, then the whole point is that we end up with access >> to their geographic data. > [...] > You are obviously reading section 4.5 in a different way that I do. > [...] > For me it looks like business users can feel safe with their data if they > do not make derivative databases, for example by enhancing their > own data by taking tags from OSM database. Drawing their own data > on top of OSM basemap is OK, isn't it? Which fits in exactly with what Andy said. The key word is "mix". cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Share-A-Like-non-Verifiability-because-they-are-not-publicly-accessable-tp5212191p5216880.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
Andy Allan writes: > > No. That would be avoiding the whole point of the share-alike license. > If they have geographic data that we don't have, and they mix it with > OSM data, then the whole point is that we end up with access to their > geographic data. It's called share-alike! Not > "take-ours-and-keep-yours-private"! > > Really, if people (businesses, charities, individuals or whoever) have > data they wish to keep private, they can still use OSM data > internally. If they want to "Publicly Convey this Database, any > Derivative Database, or the Database as part of a Collective > Database", then they can't avoid the licence. Hi, You are obviously reading http://www.opendatacommons.org/licenses/odbl/1.0/ , section 4.5 in a different way that I do. " a. For the avoidance of doubt, You are not required to license Collective Databases under this License if You incorporate this Database or a Derivative Database in the collection, but this License still applies to this Database or a Derivative Database as a part of the Collective Database; " For me it looks like business users can feel safe with their data if they do not make derivative databases, for example by enhancing their own data by taking tags from OSM database. Drawing their own data on top of OSM basemap is OK, isn't it? -Jukka Rahkonen- ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
On 06/24/2010 09:34 AM, Andy Allan wrote: > On Wed, Jun 23, 2010 at 9:11 AM, Oliver (skobbler) > > Really, if people (businesses, charities, individuals or whoever) have > data they wish to keep private, they can still use OSM data > internally. If they want to "Publicly Convey this Database, any > Derivative Database, or the Database as part of a Collective > Database", then they can't avoid the licence. Yes. This is a point worth making to people who are concerned that they won't be able to deny other people their freedom. You can do (pretty much) what you like in private. I do wish people would *read* the licence. ;-) - Rob. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB planet)
Hello, thanks.
Solved. I think the problem was that I was downloading the file to a remote
disk (R: mapped to \\lanserver\data)
Another question: after exporting the whole planet (recently) to Postgres, what
is the size of the largest table created (which I presume will take up 80% of
the whole DB)? You can get the table size with:
SELECT pg_size_pretty(pg_total_relation_size('big_table'));
Regards,
Juan Lucas
--- On Tue, 6/22/10, Grant Slater wrote:
From: Grant Slater
Subject: Re: [OSM-talk] Failed to download 9.5 GB planet
To: "Dirk-Lüder Kreie"
Cc: talk@openstreetmap.org
Date: Tuesday, June 22, 2010, 11:29 AM
2010/6/22 Dirk-Lüder Kreie :
> Am 21.06.2010 18:12, schrieb Juan Lucas Domínguez Rubio:
>>
>> 16:23:53 (1.02 MB/s) - Connection closed at byte 1621101924. Retrying.
>>
>> --16:23:53--
>> http://ftp.heanet.ie/mirrors/openstreetmap.org/planet-100618.osm.bz2
>> (try: 2) => `planet_100618.osm.bz2'
>> Connecting to ftp.heanet.ie|193.1.193.64|:80... connected.
>> HTTP request sent, awaiting response... 500 ( Arithmetic result exceeded 32
>> bits. )
>> 16:23:53 ERROR 500: ( Arithmetic result exceeded 32 bits. ).
>
> Try a different mirror, or try it via ftp. (if that's possible)
>
Can anyone confirm if there is a problem with the heanet mirror?
Juan: you could try FTP or rsync too.
ftp://ftp.heanet.ie/mirrors/openstreetmap.org/planet-100618.osm.bz2
or
rsync://ftp.heanet.ie/mirrors/openstreetmap.org/planet-100618.osm.bz2
Regards
Grant
___
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-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
On Wed, Jun 23, 2010 at 9:11 AM, Oliver (skobbler) wrote: > > Hello everybody, > > I am still concerned that some business users cannot make use of > OpenStreetMap data because of the Share-Alike-rule as they don't want or > cannot share proprietary data. Umm, if you want it so that some people are exempt from sharing their data, then having a share-alike license is the wrong license. Ergo, if you want a share-alike license, people have to share their data. If you want people to not share some data, you want a non-share-alike license. > I have the following interpretation in mind that could make the life of > business users easier without undermining the generic Share-Alike rule: Don't call them "business users", since that's just smearing lots of other businesses. Call them "people trying to wriggle out of the license". > Would it be possible that all objects and attributes of these objects that > are non-publicly accessible to declare as non-substantial due to the lack of > verifiability? No. That would be avoiding the whole point of the share-alike license. If they have geographic data that we don't have, and they mix it with OSM data, then the whole point is that we end up with access to their geographic data. It's called share-alike! Not "take-ours-and-keep-yours-private"! Really, if people (businesses, charities, individuals or whoever) have data they wish to keep private, they can still use OSM data internally. If they want to "Publicly Convey this Database, any Derivative Database, or the Database as part of a Collective Database", then they can't avoid the licence. Cheers, Andy ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
Hi, Oliver (skobbler) wrote: >> He shouldn't draw then into the database, as this mixes OSM data and his >> own data. Why not just use a layer on top of the OSM data? > > One of the big advantages of OSM is that you the "drawing tools". An option > would be to create a blank database on top of the OSM data by using the OSM > tools. I think that OSM as a whole - and this is not a legal issue - needs to improve interoperability. What we're currently seeing is "import mania", poeple trying to stuff every possible bit of information into OSM because that's the easiest way for them to use it in conjunction with OSM data. There is too much geodata in the world for this to be sustainable - OSM must stick to things that mappers map. I hope that it will become gradually easier to mix'n'match OSM with other data at the rendering stage so that people will not feel compelled to upload any rubbish to OSM just becasue they want to render it on a map. That will then also make it easier for those who wish to create produced works from several databases, one of them being OSM, without tainting their private data in the process. Bye Frederik ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-A-Like (non-) Verifiability because they are not publicly accessable
>He shouldn't draw then into the database, as this mixes OSM data and his >own data. Why not just use a layer on top of the OSM data? One of the big advantages of OSM is that you the "drawing tools". An option would be to create a blank database on top of the OSM data by using the OSM tools. Regards, Oliver -- View this message in context: http://gis.638310.n2.nabble.com/Share-A-Like-non-Verifiability-because-they-are-not-publicly-accessable-tp5212191p5216612.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
