[OSM-talk] Mapnik: rendering forest or wood
I think the mapnik rendering of forests could be improved. ATM, landuse=forest is not distinguishable from recreation_ground. Even if forest are often used as places for recreation in Germany, rendering both areas the same way is not optimal. For outside activities you want where wood or forest is located. Thus I'd like to propose to render both landuse=forest and natural=wood the same way in a darkish green. That's also how osmarender deals with these areas. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
80n wrote: > On Fri, Feb 22, 2008 at 8:23 AM, Mark Williams <[EMAIL PROTECTED]> > wrote: > >> Stephen Hope wrote: >>> This would be good. But even better, let me select a portion of a >>> track log and upload it. My track logs tend to be a nightmarish >>> tangle, with possibly hours of stuff before, after and during the >>> interesting bits. I can use them because I was there, and know where >>> I went, when and why (this is why I take notes). But somebody looking >>> at the raw track would actually be confusing, and possibly wrong. >>> >>> However - bits that I'm actually mapping tend to be much better - >>> actually tracking roads, paths etc. If I could easily select the bad >>> bits of the track log (just points) in JOSM and remove them, then >>> upload the rest, I'd be willing to put them up. >>> >>> I keep meaning to go back over my old track logs (all of which I have) >>> and clean them up with some 3rd party tool, bit I always seem to have >>> new stuff to work on instead. >>> >>> On 22/02/2008, Frederik Ramm <[EMAIL PROTECTED]> wrote: I think we should provide a track upload facility within JOSM. I started work on that once but got distracted, maybe its time to revisit that. >>> Stephen >> One other point is that a track layer will highlight all our homes in a >> very public way; at present you have to download something eg josm + GPX >> trackdata to see this at a meaningful scale (ie not Potlatch, for this >> purpose). This effectively reduces the casual browsers chance of >> noticing the possibility, but posting it publicly hangs out a banner. >> >> I am aware of at least one user with a node marking his home, so we >> don't all care, but it's worth considering first! >> >> Also, I don't really see the utility of this, even after reading the >> preceding posts. You can't use the data from a visual map of traces for >> much, and areas where doubt exists eg changes to roads, will have a mass >> of new & old to make a mess there... >> > > 1) They prove the source of your contribution, in the same way that a good > Wikipedia article cites its sources. Several of the reasons listed here: > http://en.wikipedia.org/wiki/Wikipedia:Citing_sources#Why_sources_should_be_citedare > equally applicable to OSM. > > 2) Track logs from multiple sources are aggregated. Different users, at > different times, and using different equipment will result in a much better > dataset than a single track log ever can. It is very common for parts of a > single track to be off by a considerable amount, this type of error can be > reduced and eliminated if there are multiple tracks to refer to. If you > download the tracks for a part of the M25 motorway, for example, you will > see that the aggregated result is much better than any one single track. > You'll also notice outlier tracks which can easily be discounted. > > 3) There may be uses of the track logs in the future that have not yet been > developed or thought of. For example, it might be that detection of edits > in places that are distant from any track log could help to monitor for > vandalism, or indicate a higher priority for peer review. Analysis of > average speed and direction might help routing software to determine journey > times and one-ways streets. etc. etc. > > You raise the point about some of your tracklogs being a bit of a mess. In > my opinion you can and should still upload them. Any analysis of tracks > will have to use statistical techniques to filter out noise, so anomalies > will get removed as part of this process. In fact, many years from now, > historians and archaeologists will be horrified that our enormous archive of > GPS data was so badly mutilated before it was uploaded. > > 80n > > I wasn't saying not to upload them - just that I'm personally not that keen to see a raw GPS track layer on the map. I do upload them, that's why it would show up... Mark ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Continuous audio in JOSM on tracks without waypoints
On 21/02/2008 23:56, David Earl wrote: > One thing I realised just cycling along this evening, having stepped > back from the project for a while, is that when you don't have a > waypoint at the start it is hard to synchronise on a marker, because it > they are sampled, not related to any specific point, so to make this > truly useful I need to add something to let you adjust or identify the > sync point. What I did in the end (now checked in for tomorrow's build) was to give a new operation "Make Audio Marker At Play Head" on the right button menu of an audio layer (particularly the artificial one arising from "Make Sampled Audio Layer"). You play the audio (typically from the automatically generated marker before the landmark where you will synchronise, ignoring what the sound track is saying) and pause audio when you see the orange play head arrow reach the sync landmark. Then choose "Make Audio Marker At Play Head" and it will make you a marker, which you can then choose to synchronise with. (You really need to have been moving as you pass the landmark to ensure there is no ambiguity as to the time at the location you pause at.) Synchronise the audio to that new point as before, by playing from that new marker, pausing when the audio reaches your "NOW" cue, and choose "Synchronize Audio". If your dictaphone was started before the first point of the GPS track, you'll need to use the rewind button to step back to the sync cue - not play from an earlier marker, as that would then sync to that marker, which is not what you want. Note that you can also use "Make Audio Marker At Play Head" to add additional markers in the track, if you want to play the audio more than once or twice where the sampling didn't put a convenient marker, or if you _are_ using waypoints then at a location where you forgot to mark one. Additionally, I've set the audio tracing to be on by default (you need to see the arrow to make use of the new facility). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
On Fri, Feb 22, 2008 at 4:58 PM, Andy Allan <[EMAIL PROTECTED]> wrote: > On Thu, Feb 21, 2008 at 9:57 PM, Guilhem Bonnefille > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Is there any layer presenting ONLY raw GPS data? > > > > Actually, we have Mapnik, Osmarender, Maplint, but what about a layer > > with only raw GPS data. This could be usefull (at least for me) to > > manage my own traces. Could be usefull to easily decide if a zone need > > some GPS traces or not. > > Have you seen this? > > http://dev.openstreetmap.org/~random/gps/ > > Maybe that could be adapted to provide a tileset in addition to static > images. > Would need a pile of changes, for instance a local DB full of points, to work anywhere near efficiently -- those images were produced fairly ad-hoc and it wasn't exactly quick. And we'd need a GPS equivalent of the planet file too, because life is too short to try and query the DB through the API for any large area. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions
> in the UK some main A roads have single lane passing places and 10 > MPH speed limits while others are much higher quality than most motorways. Are these not edge cases? Any general case model of classification will fail at the edge cases. No classification system will map cleanly onto the real world, where there are always extremes. The current model is simple, and allows for extra tags to describe a road that differs from what the highway= tag might lead one to expect. (primary road with low bridges or narrow lanes, secondary road with dual carriageway). With our current model, we can reasonably assume for any country that a road tagged highway=motorway is of higher quality than trunk > primary > secondary etc. We can make assumptions for each different country or even region that a given tag will specify a higher or lower quality than in another country i.e. you don't go from Northern France to Iceland expecting highway=primary roads to be of the same quality. But the principle that one highway type is better than another, *in* *general*, is true everywhere. In the UK, in general, the administrative classifications Motorway > green-signed A-road > white-signed A-road > B road > unclassified road - so these reasonably map to motorway, trunk, primary etc. The current model is simple, and *generally* does not surprise the user. The guiding principles of OSM. - Dan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
On Thu, Feb 21, 2008 at 9:57 PM, Guilhem Bonnefille <[EMAIL PROTECTED]> wrote: > Hi, > > Is there any layer presenting ONLY raw GPS data? > > Actually, we have Mapnik, Osmarender, Maplint, but what about a layer > with only raw GPS data. This could be usefull (at least for me) to > manage my own traces. Could be usefull to easily decide if a zone need > some GPS traces or not. Have you seen this? http://dev.openstreetmap.org/~random/gps/ Maybe that could be adapted to provide a tileset in addition to static images. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
In message <[EMAIL PROTECTED]> Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 2:47 AM, J.D. Schmidt <[EMAIL PROTECTED]> wrote: >> I haven't >> bothered with reviving my 300 part of the 55949581 orphaned >> gpspoints, since the perlscript supplied for that operation indicates I >> have to re-enter the detailed descriptions again, and that would >> probably mean re-entering descriptions for 200+ files. It was enough of >> an ordeal the first time around. > > Hmm, that sounds counterproductive. Perhaps it would be worthwhile to > add a "quick" option to the script to just put in blank > descriptions... The script doesn't force you to add descriptions at all. IIRC it generates some default ones from the filenames. Even without descriptions the files can still be associated with their original owners and they can be restored to public status if that is what the owner wants. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] do we have a map feature for this? :)
On 22/02/2008, Jo <[EMAIL PROTECTED]> wrote: > Michael Collinson wrote: > > At 04:28 PM 2/22/2008, Igor Brejc wrote: > > > >> Sat-nav lorry stuck in farm lane: > >> http://news.bbc.co.uk/2/hi/uk_news/wales/north_east/7257555.stm > >> > > > > hgv=no;no;no;no;no > > > > hgv=the_previous_one_is_still_stuck_a_bit_further_down_the_road :-) > Nice. BBC even has a photo of a sign banning lorries on that road. -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
On Fri, Feb 22, 2008 at 2:47 AM, J.D. Schmidt <[EMAIL PROTECTED]> wrote: > I haven't > bothered with reviving my 300 part of the 55949581 orphaned > gpspoints, since the perlscript supplied for that operation indicates I > have to re-enter the detailed descriptions again, and that would > probably mean re-entering descriptions for 200+ files. It was enough of > an ordeal the first time around. Hmm, that sounds counterproductive. Perhaps it would be worthwhile to add a "quick" option to the script to just put in blank descriptions... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] do we have a map feature for this? :)
Michael Collinson wrote: > At 04:28 PM 2/22/2008, Igor Brejc wrote: > >> Sat-nav lorry stuck in farm lane: >> http://news.bbc.co.uk/2/hi/uk_news/wales/north_east/7257555.stm >> > > hgv=no;no;no;no;no > hgv=the_previous_one_is_still_stuck_a_bit_further_down_the_road :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] do we have a map feature for this? :)
At 04:28 PM 2/22/2008, Igor Brejc wrote: >Sat-nav lorry stuck in farm lane: >http://news.bbc.co.uk/2/hi/uk_news/wales/north_east/7257555.stm hgv=no;no;no;no;no ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] Attempt to clarify
On Fri, Feb 22, 2008 at 03:56:40PM +0100, Frederik Ramm wrote: > my back and leave if you were to win. I'd just quietly grumble and > point out my ethical superiority. I think it is not helpfull to claim ethical superiority in this debate. For the record : there is, in my opinion, nothing ethically wrong with putting a value on intellectual work and demanding compensation (money, attribution, sex, ...) for it. cu bart ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
[OSM-talk] do we have a map feature for this? :)
Sat-nav lorry stuck in farm lane: http://news.bbc.co.uk/2/hi/uk_news/wales/north_east/7257555.stm -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Relation history
it's the right URL, but: http://trac.openstreetmap.org/ticket/557 patches welcome I'm guessing. On Fri, Feb 22, 2008 at 2:39 PM, Ben Laenen <[EMAIL PROTECTED]> wrote: > Can someone tell me if this is the correct url to get the complete > history of a relation from the OSM API: > > http://www.openstreetmap.org/api/0.5/relation/5286/history > > since it only returns "Application errors" to me. > > Thanks, > Ben > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
Hello, On Fri, 22 Feb 2008 10:01:39 +0100, Jo <[EMAIL PROTECTED]> wrote: > Say I would like to set up a server myself. I want to: > > * show highways more with the colours used on Michelin maps > * show a bicycle map as three overlays (transparent, with a possibility > to switch them on and off) > * show bus routes for each bus separately as overlays (transparent layers) I'm *very* interested in doing something similar, particularly the bus routes as transparent overlays. If you make any progress please keep me in the loop! It will be for this web site: www.oneplanetsutton.org Kind regards, Tom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Relation history
Can someone tell me if this is the correct url to get the complete history of a relation from the OSM API: http://www.openstreetmap.org/api/0.5/relation/5286/history since it only returns "Application errors" to me. Thanks, Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, Feb 22, 2008 at 2:29 PM, Andy Allan <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 22, 2008 at 2:18 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 22, 2008 at 1:50 PM, Jo <[EMAIL PROTECTED]> wrote: > > > Do the transparent layers take the same amount of time to render as the > > > base layer for a given area? > > > > > > > > > This will depend entirely on what you put on them, and how you > > organise that data in the database. > > Assuming your transparent layer only has a few lines (ie: bus routes) > > and you keep this data in a separate table, then they'll render > > faster, probably a lot faster. > > ...than normal background tiles. I don't think Dave meant to imply > that it's quicker to render "background tiles" + "overlay tiles" than > it is to render one set of "background + overlay" tiles. Or in other > words, every line that gets drawn takes a certain amount of time. It > doesn't matter what the background colour is. > > If you only want to draw some overlays for the standard OSM tiles then > you're quicker just drawing the overlays. > I was answering the question: is mapnik rendering speed limited by pixel area, or by data density? To which the answer is data density for the base tiles. I'm still trying to work out what Andy thinks I said, which probably says more about my brain than his. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] Database Law / extracting non-significant amounts of data, and ODL
Frederik Ramm wrote: > What would be the legal situation? The data is not copyrightable, and > its extraction does not fall unter database law. Would we, in spite > of that, try to bind the user to ODL restrictions (attribution/share- > alike) by contract? No. cheers Richard ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, Feb 22, 2008 at 2:18 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 1:50 PM, Jo <[EMAIL PROTECTED]> wrote: > > Do the transparent layers take the same amount of time to render as the > > base layer for a given area? > > > > > This will depend entirely on what you put on them, and how you > organise that data in the database. > Assuming your transparent layer only has a few lines (ie: bus routes) > and you keep this data in a separate table, then they'll render > faster, probably a lot faster. ...than normal background tiles. I don't think Dave meant to imply that it's quicker to render "background tiles" + "overlay tiles" than it is to render one set of "background + overlay" tiles. Or in other words, every line that gets drawn takes a certain amount of time. It doesn't matter what the background colour is. If you only want to draw some overlays for the standard OSM tiles then you're quicker just drawing the overlays. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, Feb 22, 2008 at 2:09 PM, Chris Jones <[EMAIL PROTECTED]> wrote: > On Fri, 22 Feb 2008, Jo wrote: > > > >>> 2. What do I need? PostgreSQL? Python? What else? > >> > >> See http://wiki.openstreetmap.org/index.php/Mapnik > > It's rather short. Is it really that simple...? How often is the planet > file > > generated? Say I would like to have daily updates instead of weekly. Is > that > > possible? I guess I should just try it... > > You can complecate it more if you want to render things on demand rather > than prerender everything, but thats basicly all thats needed produce a > bunch of tiles. > > There are daily and even hourly 'diffs', i dont know if osm2pgsql or any > other tool can update the mapnik database useing them though. > Not at the moment, but if you're only working on a smallish excerpt of the planet it would probably be feasible to apply the daily diff and reimport the data to postgres in not-much-time. This doesn't really work for the whole planet where importing alone seems to be taking about 4 hours... this would probably go faster if I had faster disks, and if osm2pgsql could take advantage of all my CPUs - but that's non-trivial. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-legal-talk] Contracts: What would we need from re-distributors?
Hi, currently, there's a multitude of ways to access OSM data - the planet file, the API, tons of derived extracts and so on. Our license says there must be proper attribution but that's about it; you can redistribute OSM data in any way you like. A license like the ODL that tries to do by contract where it cannot achieve its goals through database law will require the user's consent, i.e. he or she must somehow say "yes I agree to enter into this contract", otherwise it is worthless. In the world around us, this is commonly done by putting stickers on CDs that say "by breaking this open you agree to ...", or web pages that require you to make an explicit "I agree" click or so. Would we, if we were to employ something like the ODL, in the future have to force all redistributors to install such mechanisms? For example, let us assume there is someone, today, who offers to ship you the planet file on CD-ROM for $10 (with all the attribution etc). Will this person in the future have to be forced to put a sticker on his CD saying "by opening this you agree to ..."? Or, a less hypothetical example: I currently redistribute planet file excerpts; they can be simply and automatically be downloaded by everyone, with no session handling, no redirects or "I agree" buttons and so on. Will I have to change that in the future to disable automatic downloading (because machines cannot become party to a contract!), install a captcha and a big fat "I agree" button before every download (or alternatively, have users register with name and password on my site to give me their agreement)? Or could we just distribute everything as we do now, adding a note that says "by using this you agree..."? The latter seems to be equivalent to the "browse-wrap" stuff someone mentioned, and the former would be "click-wrap". Maybe I'm too pessimistic here but if it turned out that we need click-wrap because browse-wrap is unreliable, that could cause considerable trouble, especially where we're today relying on automatic downloads without registration. Ultimately we might have to require an account for downloading as well, and find a way to force all redistributors to make sure that all recipients have also "clicked" in some way. Wouldn't exactly sound like freedom to me...? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, Feb 22, 2008 at 2:09 PM, Chris Jones <[EMAIL PROTECTED]> wrote: > On Fri, 22 Feb 2008, Jo wrote: > > > >>> 2. What do I need? PostgreSQL? Python? What else? > >> > >> See http://wiki.openstreetmap.org/index.php/Mapnik > > It's rather short. Is it really that simple...? How often is the planet > file > > generated? Say I would like to have daily updates instead of weekly. Is > that > > possible? I guess I should just try it... > > You can complecate it more if you want to render things on demand rather > than prerender everything, but thats basicly all thats needed produce a > bunch of tiles. See also http://wiki.openstreetmap.org/index.php/Deploying_your_own_Slippy_Map > There are daily and even hourly 'diffs', i dont know if osm2pgsql or any > other tool can update the mapnik database useing them though. I'm not sure, but you can always apply the diffs to the planet file itself and re-import. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, Feb 22, 2008 at 1:50 PM, Jo <[EMAIL PROTECTED]> wrote: > Do the transparent layers take the same amount of time to render as the > base layer for a given area? > This will depend entirely on what you put on them, and how you organise that data in the database. Assuming your transparent layer only has a few lines (ie: bus routes) and you keep this data in a separate table, then they'll render faster, probably a lot faster. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, 22 Feb 2008, Jo wrote: >>> 2. What do I need? PostgreSQL? Python? What else? >> >> See http://wiki.openstreetmap.org/index.php/Mapnik > It's rather short. Is it really that simple...? How often is the planet file > generated? Say I would like to have daily updates instead of weekly. Is that > possible? I guess I should just try it... You can complecate it more if you want to render things on demand rather than prerender everything, but thats basicly all thats needed produce a bunch of tiles. There are daily and even hourly 'diffs', i dont know if osm2pgsql or any other tool can update the mapnik database useing them though. -- Chris Jones, SUCS Admin http://sucs.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
Do the transparent layers take the same amount of time to render as the base layer for a given area? Polyglot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] Attempt to clarify
> But personally, I *do* have a principled objection to share-alike. I > think it is the choice of the petty-minded, of people who can't let > go, who praise themselves as giving something away when in fact > they're just laying out a bait; people who really want to control and > enforce and sue and compel; people who would not hesitate one second > to employ DRM and stuff if it could be used to further their goals. The problem with this view is that it has no correspondence with reality. Or, at least, it _could_ be that all these people who say "I support copyleft" but also say "DRM is evil" are lying to you and part of a large global conspiracy to secretly keep PD geodata from the world for their own evil ends, but if you are that paranoid, I really can't help you. Denying that your opponents hold the views they hold is not normally a good way to engage in debate. "Well, I think X and Y" "No, you don't!" ... Also, I would take issue with your loaded language: "bait" implies trap implies hidden, but there's nothing hidden about the licensing terms of OSM. You can choose to use the data and follow them, or not. "control and enforce and sue and compel" - the law of the land currently controls and enforces and compels me to drive on the correct side of the road, to pay for goods instead of stealing them, and so on. Not all enforcement and compelling is automatically wrong. "people who can't let go" - if you go into a shop and take something off the shelf and walk out with it, and the security guard stops you, do you accuse him of being "someone who can't let go"? The difference here is that some OSM participants want to trade, and you want to give away. Neither is ethically superior or inferior. Gerv ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] josm 'move sensitivity'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Hughes schrieb: > I suspect the real answer is that you probably want quite a high > threshold for ways (it's very rare for me to really want to move > an entire way, so having to try hard is good) but a very low > threshold (if any at all) for nodes, which I often want to move > by quite small amounts and which I very rarely move accidentally. Then "select" should become an extra "mode" again. (well, I think that regardless) - -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHvtEKFUbODdpRVDwRAttJAKCwMAQ+FjvWOE9Nxkpndb3wA4OhUQCgnjgW WswTF5IU4KuyPMF9GscWL4Y= =4pUm -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
Hi Chris, Thanks for your answer. Chris Jones wrote: > On Fri, 22 Feb 2008, Jo wrote: > >> Say I would like to set up a server myself. I want to: >> >> * show highways more with the colours used on Michelin maps >> * show a bicycle map as three overlays (transparent, with a possibility >> to switch them on and off) >> * show bus routes for each bus separately as overlays (transparent >> layers) >> >> 1. Is this possible? > > Yes Great. > >> 2. What do I need? PostgreSQL? Python? What else? > > See http://wiki.openstreetmap.org/index.php/Mapnik It's rather short. Is it really that simple...? How often is the planet file generated? Say I would like to have daily updates instead of weekly. Is that possible? I guess I should just try it... > >> 3. What kind of server would be good for this? Would an AMD64 with one >> core be able to do this? Do I need more cores? Does 64 bit processing >> help? Or would I be just as well off with a Core2Duo or even a >> Pentium 4? > > Any recent processor is fine, obviously the faster the core(s) the > more tiles you can render in a given time. So an AMD64 would be OK then. > >> 4. For the disks I was considering to set up a RAID1 mirror with 2 disks >> of 750 GB. I guess that would be sufficient? > > How much storage you need depends on how much of the world you would > like to render and to what zoom level. > > I render the whole UK to level 5 and just Wales to zoom 16, this uses > a mere 450MB > > In my experience each zoom level is roughly 2.5x bigger (in terms of > disk space) than the previous. > > Unless your planning to serve the whole world, to hundreds of clients > at a time (which your connection info below suggests your not) RAID1 > is massive overkill! The regularly requested tiles will get cached in > memory anyway further reducing the disk speed requirements. I'm not sure if I want the whole world. I do want to render Belgium and probably a good part of mainland Europe. The server would also be used for my own purposes. Firewall, OpenLDAP, Postfix, HTTP, Proxy server, Asterisk, maybe MythTV, LTSP, Nagios. I simply feel more comfortable with a RAID1 setup. I wouldn't mind it uses spare cycles to render a map. > > I serve (pre-rendered) tiles from a NSLU2* running Debian with a USB > stick for storage. This setup quite happily serves ~150 tiles per second. > > *http://en.wikipedia.org/wiki/NSLU2 > >> I would like to do this from 'home' with a connection that has a fixed >> IP address and 1 or 2 Mbps upload. I'll probably be shaping the traffic >> to limit it and make my own internet connection still usable. > > With a 2 Mbps upload you should be able to serve about 40 tiles per second That should be enough. I'll probably shape it down to 700kbps then. Polyglot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] rendering with mapnik, what do I need?
On Fri, 22 Feb 2008, Jo wrote: > Say I would like to set up a server myself. I want to: > > * show highways more with the colours used on Michelin maps > * show a bicycle map as three overlays (transparent, with a possibility > to switch them on and off) > * show bus routes for each bus separately as overlays (transparent layers) > > 1. Is this possible? Yes > 2. What do I need? PostgreSQL? Python? What else? See http://wiki.openstreetmap.org/index.php/Mapnik > 3. What kind of server would be good for this? Would an AMD64 with one > core be able to do this? Do I need more cores? Does 64 bit processing > help? Or would I be just as well off with a Core2Duo or even a Pentium 4? Any recent processor is fine, obviously the faster the core(s) the more tiles you can render in a given time. > 4. For the disks I was considering to set up a RAID1 mirror with 2 disks > of 750 GB. I guess that would be sufficient? How much storage you need depends on how much of the world you would like to render and to what zoom level. I render the whole UK to level 5 and just Wales to zoom 16, this uses a mere 450MB In my experience each zoom level is roughly 2.5x bigger (in terms of disk space) than the previous. Unless your planning to serve the whole world, to hundreds of clients at a time (which your connection info below suggests your not) RAID1 is massive overkill! The regularly requested tiles will get cached in memory anyway further reducing the disk speed requirements. I serve (pre-rendered) tiles from a NSLU2* running Debian with a USB stick for storage. This setup quite happily serves ~150 tiles per second. *http://en.wikipedia.org/wiki/NSLU2 > I would like to do this from 'home' with a connection that has a fixed > IP address and 1 or 2 Mbps upload. I'll probably be shaping the traffic > to limit it and make my own internet connection still usable. With a 2 Mbps upload you should be able to serve about 40 tiles per second -- Chris Jones, SUCS Admin http://sucs.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
On Fri, Feb 22, 2008 at 8:23 AM, Mark Williams <[EMAIL PROTECTED]> wrote: > Stephen Hope wrote: > > This would be good. But even better, let me select a portion of a > > track log and upload it. My track logs tend to be a nightmarish > > tangle, with possibly hours of stuff before, after and during the > > interesting bits. I can use them because I was there, and know where > > I went, when and why (this is why I take notes). But somebody looking > > at the raw track would actually be confusing, and possibly wrong. > > > > However - bits that I'm actually mapping tend to be much better - > > actually tracking roads, paths etc. If I could easily select the bad > > bits of the track log (just points) in JOSM and remove them, then > > upload the rest, I'd be willing to put them up. > > > > I keep meaning to go back over my old track logs (all of which I have) > > and clean them up with some 3rd party tool, bit I always seem to have > > new stuff to work on instead. > > > > On 22/02/2008, Frederik Ramm <[EMAIL PROTECTED]> wrote: > >> I think we should provide a track upload facility within JOSM. I > >> started work on that once but got distracted, maybe its time to > >> revisit that. > >> > > > > Stephen > > One other point is that a track layer will highlight all our homes in a > very public way; at present you have to download something eg josm + GPX > trackdata to see this at a meaningful scale (ie not Potlatch, for this > purpose). This effectively reduces the casual browsers chance of > noticing the possibility, but posting it publicly hangs out a banner. > > I am aware of at least one user with a node marking his home, so we > don't all care, but it's worth considering first! > > Also, I don't really see the utility of this, even after reading the > preceding posts. You can't use the data from a visual map of traces for > much, and areas where doubt exists eg changes to roads, will have a mass > of new & old to make a mess there... > 1) They prove the source of your contribution, in the same way that a good Wikipedia article cites its sources. Several of the reasons listed here: http://en.wikipedia.org/wiki/Wikipedia:Citing_sources#Why_sources_should_be_citedare equally applicable to OSM. 2) Track logs from multiple sources are aggregated. Different users, at different times, and using different equipment will result in a much better dataset than a single track log ever can. It is very common for parts of a single track to be off by a considerable amount, this type of error can be reduced and eliminated if there are multiple tracks to refer to. If you download the tracks for a part of the M25 motorway, for example, you will see that the aggregated result is much better than any one single track. You'll also notice outlier tracks which can easily be discounted. 3) There may be uses of the track logs in the future that have not yet been developed or thought of. For example, it might be that detection of edits in places that are distant from any track log could help to monitor for vandalism, or indicate a higher priority for peer review. Analysis of average speed and direction might help routing software to determine journey times and one-ways streets. etc. etc. You raise the point about some of your tracklogs being a bit of a mess. In my opinion you can and should still upload them. Any analysis of tracks will have to use statistical techniques to filter out noise, so anomalies will get removed as part of this process. In fact, many years from now, historians and archaeologists will be horrified that our enormous archive of GPS data was so badly mutilated before it was uploaded. 80n > > Mark > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] josm 'move sensitivity'
In message <[EMAIL PROTECTED]> Francisco R. Santos <[EMAIL PROTECTED]> wrote: > Yes, I had to reconfigure it, changing the threshold from 15 to 5 pixels to > make it work smooth (edit.initial-move-threshold=5). Look at this thread: > > http://lists.openstreetmap.org/pipermail/josm-dev/2008-January/000656.html The current default is certainly unusable, at least for nodes, so thanks for letting me know how to fix it. I suspect the real answer is that you probably want quite a high threshold for ways (it's very rare for me to really want to move an entire way, so having to try hard is good) but a very low threshold (if any at all) for nodes, which I often want to move by quite small amounts and which I very rarely move accidentally. In fact almost always when I do move something by accident it is because I was trying to move a node but clicked slightly too far away and hence moved the way instead. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] josm 'move sensitivity'
Excellent - config options are a good thing ;-) thanks On Fri, Feb 22, 2008 at 8:20 PM, Francisco R. Santos <[EMAIL PROTECTED]> wrote: > Hi Franc > > Yes, I had to reconfigure it, changing the threshold from 15 to 5 pixels > to make it work smooth (edit.initial-move-threshold=5). Look at this > thread: > > http://lists.openstreetmap.org/pipermail/josm-dev/2008-January/000656.html > > Regards, > Quico > > On Fri, Feb 22, 2008 at 8:18 AM, Franc Carter <[EMAIL PROTECTED]> > wrote: > > > > > Hi, > > > > I just upgraded josm after 'sometime' and the amount of distance I have > > to drag > > a node befre it will move has increased - I can't find a setting to > > change this, > > am I being blind ? > > > > thanks > > > > -- > > Franc > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > > > > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Never run out of batteries again!
On Thu, Feb 21, 2008 at 10:08:06AM -, Andy Robinson (blackadder) wrote: > I remember those rim running dynamos on my bike as a kid. I hated them > because they made a load of noise and you could really feel the resistance. > It amazes me that nobody has come up with a simpler and more efficient > solution. Nave dynamos are the norm nowadays on bikes : no extra noise and an the increase in resistance is not noticeable. cu bart ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] josm 'move sensitivity'
Hi Franc Yes, I had to reconfigure it, changing the threshold from 15 to 5 pixels to make it work smooth (edit.initial-move-threshold=5). Look at this thread: http://lists.openstreetmap.org/pipermail/josm-dev/2008-January/000656.html Regards, Quico On Fri, Feb 22, 2008 at 8:18 AM, Franc Carter <[EMAIL PROTECTED]> wrote: > > Hi, > > I just upgraded josm after 'sometime' and the amount of distance I have to > drag > a node befre it will move has increased - I can't find a setting to change > this, > am I being blind ? > > thanks > > -- > Franc > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] rendering with mapnik, what do I need?
Hi, Say I would like to set up a server myself. I want to: * show highways more with the colours used on Michelin maps * show a bicycle map as three overlays (transparent, with a possibility to switch them on and off) * show bus routes for each bus separately as overlays (transparent layers) 1. Is this possible? 2. What do I need? PostgreSQL? Python? What else? 3. What kind of server would be good for this? Would an AMD64 with one core be able to do this? Do I need more cores? Does 64 bit processing help? Or would I be just as well off with a Core2Duo or even a Pentium 4? 4. For the disks I was considering to set up a RAID1 mirror with 2 disks of 750 GB. I guess that would be sufficient? About these transparent overlays. Do they take as long as generating the base layer? Or are they easier on the processing? I would like to do this from 'home' with a connection that has a fixed IP address and 1 or 2 Mbps upload. I'll probably be shaping the traffic to limit it and make my own internet connection still usable. Polyglot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
Stephen Hope wrote: > This would be good. But even better, let me select a portion of a > track log and upload it. My track logs tend to be a nightmarish > tangle, with possibly hours of stuff before, after and during the > interesting bits. I can use them because I was there, and know where > I went, when and why (this is why I take notes). But somebody looking > at the raw track would actually be confusing, and possibly wrong. > > However - bits that I'm actually mapping tend to be much better - > actually tracking roads, paths etc. If I could easily select the bad > bits of the track log (just points) in JOSM and remove them, then > upload the rest, I'd be willing to put them up. > > I keep meaning to go back over my old track logs (all of which I have) > and clean them up with some 3rd party tool, bit I always seem to have > new stuff to work on instead. > > On 22/02/2008, Frederik Ramm <[EMAIL PROTECTED]> wrote: >> I think we should provide a track upload facility within JOSM. I >> started work on that once but got distracted, maybe its time to >> revisit that. >> > > Stephen One other point is that a track layer will highlight all our homes in a very public way; at present you have to download something eg josm + GPX trackdata to see this at a meaningful scale (ie not Potlatch, for this purpose). This effectively reduces the casual browsers chance of noticing the possibility, but posting it publicly hangs out a banner. I am aware of at least one user with a node marking his home, so we don't all care, but it's worth considering first! Also, I don't really see the utility of this, even after reading the preceding posts. You can't use the data from a visual map of traces for much, and areas where doubt exists eg changes to roads, will have a mass of new & old to make a mess there... Mark ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Raw GPS layer
This would be good. But even better, let me select a portion of a track log and upload it. My track logs tend to be a nightmarish tangle, with possibly hours of stuff before, after and during the interesting bits. I can use them because I was there, and know where I went, when and why (this is why I take notes). But somebody looking at the raw track would actually be confusing, and possibly wrong. However - bits that I'm actually mapping tend to be much better - actually tracking roads, paths etc. If I could easily select the bad bits of the track log (just points) in JOSM and remove them, then upload the rest, I'd be willing to put them up. I keep meaning to go back over my old track logs (all of which I have) and clean them up with some 3rd party tool, bit I always seem to have new stuff to work on instead. On 22/02/2008, Frederik Ramm <[EMAIL PROTECTED]> wrote: > I think we should provide a track upload facility within JOSM. I > started work on that once but got distracted, maybe its time to > revisit that. > Stephen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk