Re: [OSM-talk] Current Garmin units with unlimited tracklog?
On 3 Jul 2012, at 16:16, Shaun McDonald wrote: The Garmin Edge 800 stores in some .fit format rather than GPX. I've still not found some tools to batch convert from that format to .gpx. The ANT SDK has some sample code for decoding .fit files: http://www.thisisant.com/pages/developer-zone/fit-sdk The sample just dumps out lat/lon/timestamp samples, but it's easy enough to munge into gpx or the like. -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Pitiful proceedings - as usual
TimSC wrote: I suggest as many tasks as possible be moved into domains were people actually have the skills to help out. Then I suggest you do it, rather than just suggest it. If you believe we need a request for help page on the wiki then there's nothing stopping you from: - Suggesting this page - Creating this page - Identifying people you think might require help - Collect their requests and add them to the page - Identify people you think could implement these tasks - Convince those people they should implement these tasks - Monitor implementation progress and update the page So far you seem to be at step 0. -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Adding a further 250, 000 UK roads quickly using a Bot?
Ed Avis wrote: Lastly, I don't believe that adding data from external sources discourages contributors. Quite the opposite. It is a blank canvas that puts people off. The way to bring in contributors is to show a map with a few missing details that are so tempting to fix 'just one thing'... Is there an example of a road import that has led to an increase in contributors? I thought that in most cases it had the exact opposite effect. IMO the blank canvas is what pulls people in: an area that's 90% already there finds it harder to attract new mappers as it already looks done (filling in all the footpaths, post boxes, pubs, etc, is something you tend to do once you're already hooked). Comparisons to a reference source like OS are still valuable, but more as a way to prioritise mapping: a vague heatmap of patchy areas is more motivating to me than than an exhaustive list of streets. If you want a 1:1 copy of the OS data, why not just use the OS data? -dair ___ d...@refnum.com http://www.refnum.com/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Adding a further 250, 000 UK roads quickly using a Bot?
Peter Miller wrote: There is suggestion raised by a number of people, but refuted by others that imports reduce the number of contributors. It has been denied, not refuted. I think the closest there is to real data on the effect is: http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community-ii Personally I feel the impact of road network imports is more substantial than of any other kind. Importing bus stops or post boxes feels like a step forward, importing a road network feels like a step back (why that should be the case, I don't know: perhaps due to the greater visibility of roads on the default map). -dair ___ d...@refnum.com http://www.refnum.com/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Adding a further 250, 000 UK roads quickly using a Bot?
Ed Avis wrote: I suggest, but cannot prove, that seeing an entirely blank canvas doesn't entice you to start adding to the map, which must necessarily involve adding small bits at a time. Actually, seeing a blank canvas in my local area was exactly my motivation. But everyone is different, as proved by us having had the exact opposite reasons for starting. :-) However, we do have some real-world evidence. There are towns which have been blank for a long time on OSM. If a blank canvas were a good way to encourage contributors, they would have been filled in by now. The fact that they are still missing suggests that the strategy of deliberately leaving an area blank and hoping for somebody to go out and survey it from scratch is not always effective. Part of that problem is that we have no way to distinguish this area is unmapped from this area is under-mapped - they both look blank. If you could rewind time to the start of OSM, an import strategy I think would have been useful would have been to start with a set of towns and create straight lines between them for roads. That makes it obvious there's something there, and that it can be improved, without having the tiger effect of going from an empty map to one which looks complete but is full of bad data. If you want a 1:1 copy of the OS data, why not just use the OS data? What I want (and I think what others want) is a map in machine-readable form which corresponds to the real world. The source it originally came from does not matter. At the data level, no. But for the longer term impact on motivation, I think it does. Things change over time of course, so perhaps people who were interested in mapping by hand will drift away and people who're more interested in automated maintenance will come in. But I can't say the latter sounds like a very interesting thing to spend my free time on. -dair ___ d...@refnum.com http://www.refnum.com/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] [Edinburgh] Road Names
Hi, At this week's Edinburgh meet-up we discussed the Council's public road name list, and how to cross-reference it with OSM to check coverage/identify missing roads. Unfortunately the council data is only available as a set of tabular PDFs, which is hard to do anything useful with, so I've converted them into a single csv file: http://bit.ly/99py7c I won't have time to do anything with it for a while, but have put it up in case anyone else from Edinburgh wants a go (the script is on github in case other councils have a similar problem). Sorry for spamming all of -gb, as this is pretty local to Edinburgh, but there's no talk-scot and everyone is on talk-gb. Having said that, we also discussed having a mapping party in/around Penicuik on April 10th, so for anyone in central Scotland/visiting the area then I think Bob will be sticking the details for that on the Edinburgh page on the wiki. -dair ___ d...@refnum.com http://www.refnum.com/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] Not-properly-Open-but-called-Open
On Sat, Jan 2, 2010 at 6:36 PM, Martin Koppenhoefer dieterdre...@gmail.comwrote: It is our main page and a closed project on the main page of OSM IMHO doesn't suit well. IMHO, a closed project on the main page is a good thing. What is the purpose of the OSM web site? It is partly to provide a way for end-users to view a map (although we provide a much simpler experience than other sites), but it is also to show people what can be done with OSM data. Those two goals have overlapped at times, but IMO the latter is more important: showcasing useful and innovative things that have been done with OSM data is more important than trying to split ourselves into open (terms and conditions will apply) and not. -dair ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Frederik Ramm wrote: And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. Is the bugs database really so different in character to the map database though? Provided there was a planet-style dump of the bug database, anyone wishing to build an external system could easily do so. It's true that lat/lon/text wouldn't be sufficient for all bugs, but how many would that model work for - 75% or more? Most bugs are either for a specific location (name is wrong, street is missing, etc), or a fairly well defined area (all the footpaths in this park need doing, there's a place=hamlet|village|etc node but there's no ways within 5km of it). There are meta-bugs too (are imported political boundaries really in the correct place, is a blank area of the map really blank or just unmapped?), but how best to track them will depend on what they are (so you might as well collect a few examples and look for patterns first). Worst-case you could simply use a lat/lon/text entry as a link to some external tracker until such time as its model could be supported (either directly, or by better integration with external trackers - although I would hope the former). But however it works behind the scenes, it gives you one place that bug reporting/visualisation can coalesce around - you go to www.* to see the map, wiki.* to see the wiki, and bugs.* for bugs. -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wikipedia POI import?
Russ Nelson wrote: TeleAtlas data is copyrighted, and when licensed is licensed under an incompatible copyright. The data you're proposing taking from Wikipedia is probably derived, via Google, from that same TeleAtlas (or Navteq) data. It doesn't seem plausible that deriving information from TA data is fine, provided it's done at arm's length via a Wikipedian who didn't read the Google Maps terms of use. These explicitly say that you must not make derivative works of the Content or any part thereof, or give access to mass downloads or bulk feeds of any Content, including but not limited to numerical latitude or longitude coordinates. -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM license change: A license to kill? - How to make a nightmare come true!
Nop wrote: I want to correct something here, there is this view of 100,000 users needing consent. The number is in fact far smaller for people who ever made an edit (about 30% of the users). It's vastly smaller still for anyone who has edited anything significant. It's an easier problem than you might think, is what I'm saying. Far easier than convincing you I don't have a satanic portal in my basement. You know what you're saying? You don't care about 10 people who are interested or want to contribute, you just care about the data of the 8000 (?) who have substantially contributed? That's not what he is saying at all. Nobody is planning to ditch contributions below some threshold for the sake of it, however things should not stall simply because one person who's contributed one post-box two years ago can't be contacted any more. All he's saying is that although we might have 100K registered users, only 30K of them have made an edits whatsoever. Looking at the stats page, only about 8K are making edits each month (a different 8K each month, sure). This paper (http://tinyurl.com/5p2w65) looked at contributors in the UK, and found that of the 1100 users in their sample some 92 of them had contributed 80% of the data (or 0.08% - about 8K again, a nice coincidence). This is a community. This is about people. At least it should be. Can't you understand why people do not trust you and suspect you are just out to grab their work when you argue like this? Nobody is trying to grab anyone's work. Doing so would take far less effort. But a licence change is effectively like an (internal) fork, and we may find that some people disagree so strongly that their contributions can't be carried forward. Or simply that we decide to be very cautious, and feel we can't take forward data we can't be 100% sure about. It's sensible to understand just what impact that would have, since we are going to lose some data no matter what (some contributors are now dead; we're not going to contact their relatives, so we either unilaterally put their data under a new licence or we remove it). Even though I am in favour of the licence itself, this way of thinking is unacceptable to me. So what are you doing to help? -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] It's all too fast...
graham wrote: Please go with Gervase's suggested timetable instead. And build in some extra process for including results of discussion by non-english-speaking countries. I know this is an unpopular view, but I disagree. I rather we had an ODbL 1.0 in as short a time as possible, so that we could look at it and decide if it is, or is not, what we want. Disclaimer: I don't have any special insight into the licence process, would have liked more feedback as it developed, and think (perhaps incorrectly) that the point of having an OSMF is to inform us of things like this. People have been talking about the licence issue for years (literally; there was an hour-long panel about it at SOTM 2007), and we have nothing to show for it other than a large number of I'm not a lawyer, but... threads. We know there are issues with the current licence, and there will be issues with ODbL 1.0 as well. But having that in front of us, in a final form, gives us a choice: is this suitable for what we want, or not? In a perfect world we would know exactly what we want, the licence would be drafted accordingly, and 1.0 could be adopted from day one. But we don't know exactly what we want, and some of us want different things. There's some overlap of course; the 1.0 needs to have some grounding in our overall goal(s), but IMO two years of talking about a new licence needs to come to a conclusion - or we should stop pretending that it ever will. I would be happy to have a bad 1.0 out sooner which was rejected by OSM (perhaps accepted by some other community, who knows), than a perfect 1.0 which never arrived. Finalising a license and adopting it are two separate things - no matter what timetable you pick for the former, the latter will take longer (since someone will pop up and say wait, we're doing what now?!?). Even if we reject 1.0, we can still tackle problems like contacting people, identifying how much data we'd need to redo if we take a strict line and say data doesn't carry forward without explicit consent, etc. -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
Frederik Ramm wrote: I'm surprised that nobody else seems to see a problem in this. Am I perhaps barking up some completely imaginary tree? Not at all; I am still reading through the draft, and have exactly the same concern. It may be I have misunderstood how this is intended to apply, but I think both 4.6a and 4.6b end up making derivative databases (effectively any mechanical processing of the original content whatsoever, IMO) problematic. In many cases, generating a file containing all of the alterations will be at least as much work as making the derivative database available (leaving aside that publishing these alterations may reveal some proprietary information, making it less likely for OSM data to be used). That is not always practical, and if all my transformations are destructive then I don't think it's even useful (compared to simply making a copy of the original database available, to ensure the source data is never lost if openstreetmap.org goes away). I'm not sure what format a file containing all of the alterations would take. Does this mean a machine-readable list of the exact transformations that were performed, or simply a human-readable summary of the transformations made? If I map our fixed point lat/lons to 32-bit floats, I will create a derivative database (32-bit floats can't represent all integers exactly, so I've lost some information and can't go back). Do I need to publish exactly which floating point value each integer was mapped to, or simply say I converted all lat/lons to floats? The latter makes more sense, but do I also need to specify that they're IEEE floats and which of the four IEEE rounding modes were used? I don't have a better phrasing for 4.6b, but I would like to allow alterations to be specified as: - A literal set of transformations to apply (e.g., a lookup table or code that could be executed to apply the transform). - A human-readable set of instructions that are reasonable Introducing reasonable means I can have my lawyer argue with yours over whether convert to floats is a reasonable summary or not, and not have to worry about being sued because I used an unusual rounding mode like round-to-infinity and forgot to mention it. It also means you can publish imported into PostGIS using this schema as your alteration, and not have to provide the literal derivative database created by your particular version of PostGIS when run on a specific platform/OS. -dair ___ d...@refnum.com http://www.refnum.com/ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[Talk-GB] Birmingham Apostrophes
Hi, Mappers in Birmingham might need to revisit some streets shortly: http://news.bbc.co.uk/1/hi/england/west_midlands/7858853.stm It does seem a bit back to front - we are constantly getting residents asking for apostrophes to be put back in somehow turns into it being a good idea to take them all out... -dair ___ d...@refnum.com http://www.refnum.com/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-legal-talk] 23rd Dec board meeting
Peter Miller wrote:
Is there not a large potential conflict of interest between SteveC in relation
to his driving this change within the Foundation and also being a director of
a company that could well benefit from the OSM project not offering a full set
of services? I don't know, but I certainly don't have the information to feel
comfortable with this initiative until we have some more facts available to
us.
I think this is uncalled for.
There are any number of technical things you need to think through before
switching from a system that pretty much works to something (anything) else.
While it's valid to question what those things are, and their significance,
I don't think you can jump from that to it all being an evil plot hatched in
CM's volcano lair.
You argue that anyone with a commercial interest in OSM (e.g., me) who's
listed on the {{PD-user}} page (me again) has a potential conflict of
interest.
You could argue that as a commercial interest who's been pushing very hard
for the licence issue to be resolved, perhaps you have some ulterior motive
too...
Nothing useful comes out of that kind of discussion.
The current progress on the licence is certainly frustrating for those of us
who are thinking about how our companies can best use and contribute to OSM,
but I suspect it's been a very frustrating process on the OSMF side as well.
E.g., we have no idea what the background to all communications with Jordan
had broken down was, or what impact that has had. It would be nice to know
what happened, but having a public discussion about that while trying to
resolve whatever the issue was probably wouldn't have been helpful.
I would definitely recommend you stand for the OSMF next year, as I think
you could make a valuable contribution to the process (e.g., I agree with
your thinking re the trademark).
I don't know if you'll find the grass is any greener though.
Although the licence project seems to be moving forward very slowly, it is
at least moving (vs what happened previously, where we had endless
GPS-vs-BSD debates on the mailing list but no real progress whatsoever).
-dair
___
d...@refnum.com http://www.refnum.com/
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Licence brief/Use Case - final call forcomments
Jonathan Harley wrote: A bit map would not be a database, but XML, csv, xls, shape files would. The interesting distinction may be vector data that is not organized in a direct searchable fashion - so, would svg (for example) be a database? H... Definitely. Searching an SVG or any XML file can be done the same way you would search a relational table with no index - by accessing each data item and examining it. Playing devil's advocate, that sounds very much like a bitmap could also be considered an un-indexed database - it's a table of (x,y,colour) where the colour is derived from OSM data. You could argue we use a system very much like this in OSM itself, querying the oceantiles.dat database to make all water or all land decisions. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Paid services from OSM
Richard Fairhurst wrote: 4.6 Access to Derivative Databases. If You publicly Use a Derivative Database You must also offer to recipients of the Derivative Database a copy in a machine readable form of: a. The entire Derivative Database; or b. A file containing all of the alterations made to the Database offered under this Licence, including any additional Data, that make up all the differences between the Database and the Derivative Database. Assuming I choose option (b), how does this work if the alterations are all subtractions? Say I'm converting a planet file for a hand-held device, and truncate all coordinates to 4 decimal places. If I don't want to publish the format for my Derivative Database, it sounds like I would need to publish a list like: - Add 0.123 to node 23 - Subtract 0.456 from node 42 Perhaps it's not worth treating the translating the Database to a less-expressive form case as different to any other modification case. But it does seem a bit like jumping through hoops, when it would be simpler to say I truncated all coordinates to 4 decimal places or even the DD is a subset of the information in version X of the D, and here's a copy of that. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Paid services from OSM
Simon Ward wrote: I¹d rather those providing the PostGIS data be obliged to provide their source (planet dumps, whatever) to the same people. ... The example was convoluted, but I hope it illustrates my point that mere translation should not be excluded from being counted as a derived database. If you're obligated to provide the source to your translation, providing access to the translation itself seems pointless. One difference between OSM usage and free software is that a great many uses of OSM will be a one way process. Tags will be discard or translated from the OSM model to a simpler model, IDs might be lost, coordinates might be truncated, etc. What's left might be useful for reconstructing OSM in an emergency, but the planet dump that went into the process would be much more helpful. If the data is just a translation from OSM (or some data literally derived from it, like a precalculated routing table/simplified graph/etc) then making that accessible is pointless. If the data is augmented or modified in a significant way then by far the best way (for everyone: OSM as a whole, and the translator) to pick up those changes would be to simply insert them into OSM and pick them up downstream. If that can't be done then, yes, those changes should be published in a form that could be used by OSM. I don't see that necessarily has to be via the translated database though. A .osm patch, or a modified planet file, would be easier to create and easier to merge in (if they turned out to be something we wanted). I believe the goal should be to pick up changes that improve OSM, rather than to use OSM as a lever to force open other file formats. If the translation doesn't improve the OSM data, and you get the source planet dump with the translation, what would you do with the translation that you couldn't do better with the planet dump? If the translation does improve the OSM data, but you get the source planet dump plus the improvements as a .osm file, requiring the translation itself be a public format seems excessive if the goal is to improve/protect OSM. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Paid services from OSM
Peter Miller wrote: 1) We clarify that a Derived Database is only deems to exist when the martial changes have occurred to the content of the DB, but not if the dataset has merely been processed into a different format. On the face of it this sounds reasonable, although I can see there being some contention over what counts as a material difference. To give a concrete example, similar to the routing service Frederik mentioned, I would like to be able to use OSM data for my company's (commercial) application. This would involve: 1. Split the planet dump into smaller units (individual countries). 2. Convert from OSM's XML format to shapefiles+Dbase files. The geometry is unchanged, but the database schema is simplified (e.g., units are made metric, highway tags are converted to a fixed set of values - this is lossy, as we might map multiple tags to the same value). 3. Convert the shapefiles+Dbase files to SQLite databases. The schema is unchanged, but each geometry is lossily compressed. 4. Build additional indices (R*Tree, full text, etc) in the SQLite database. 5. Build additional tables (for routing, more efficient rendering, etc) in the SQLite database. 6. Convert the SQLite database into our proprietary format (compressed and encrypted). Each of these steps does change the data from OSM, however none of them would be useful for improving OSM (tags are lost, node coordinates are less precise, tables get built that are no use to anyone else). Given that, providing documentation on our file format (or supplying a tool to go back from that format to XML) seems pointless. The final data is a lower-quality version of the data in OSM, so I would hope that publishing the source planet file would be sufficient. If _improvements_ are made to the data along the way (perhaps we employ someone to sit down and fix any typos in name tags) then I would like the licence to compel us to send those improvements back. I, as a mapper, don't really care if company X turns a planet file into whatever format is most appropriate for their medium (using whatever compression or proprietary format they need). What I would like to come back would be any improvements they made to the OSM data; either by merging it with another database, correcting the OSM data, etc. In (my) order of preference, those changes could be supplied as: A. Directly to OSM (if you ship data with positive improvements to OSM, you have N weeks to insert those into the OSM database and perhaps publish a list of what you changed/when/why). B. In an OSM-compatible format (if you ship data with positive improvements to OSM, you publish a .osm file at the same time so someone else can integrate them). C. In a machine-readable format (perhaps shapefiles+dbf files, after step 2 in the above). This is the worst case, since it's unlikely anyone will sift through these files and actually apply them to OSM unless a lot of new data was added over the source OSM data. You could argue that we need to publish our proprietary file format and that would avoid us having to do anything. That would be equivalent to C), and I think would make us less likely to want to use OSM data. Primarily because we want to keep that format private (since publishing it would allow decompilation of the commercial data we publish in that format), but also because I don't think it would really help OSM. I imagine any database that's optimised to minimise space would have the same problem, as your derived DB is a lower-quality version of the OSM DB. I'm not sure where you draw the line for a material change (if IDs are dropped to save space, do we even want that modified DB back? Or do we just want DBs that are a material improvement?), but thought it'd be useful to show exactly what our conversion process would look like. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] osm in flickr
Juan Lucas Dominguez Rubio wrote: Seeing other websites use OSM's data or tiles is not noticeable any more. Steve, please drop that irritating inferiority complex. OSM is a great thing. Really. I think that's pretty unfair - flickr isn't just another website, it's an incredibly popular one. Having someone like that be willing (and able) to use OSM is a significant thing IMO. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Alex Mauer wrote: In fact, highway=path makes it easier on renderers. Without using highway=path, renderers need to understand every single specialized way. snowmobileway, skiway, nordicskiway, telemarkskiway, alpineskiway, elephantway, etc. When someone introduces a new specialized way, the renderers need to be updated to understand it. I work on a (non-OSM) map renderer, and understanding every single specialised way (that you want to render) is the only sensible way to do it. Renderers have to decide up front what to show and discard everything else, as what they select completely depends on what purpose the map is meant to have. E.g., a road map renderer won't include overhead power lines - but a countryside walking map might include them for orientation. Rendering every single arbitrary way gives you output like Ito's OSM Mapper tool - fantastically useful for visualising data, but very much a specialised map. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SOTM weekend accommodation?
Simon Hewison wrote: I think Ryan Air's policy requires you to have a passport. Actually, not quite. from http://www.ryanair.com/site/EN/conditions.php?pos=MYFLIGHT I would recommend taking a passport with you if you're tempted to go with Ryanair. Two years ago my sister-in-law was refused entry to an internal Ryanair flight from London to Glasgow because she brought her (photo) driving licence rather than a passport. The reason given, and I can quote it exactly because it was so ridiculous, was that they might not let you fly back from Scotland without a passport. This meant she was unable to attend a family funeral, so despite having a direct Rynair flight from Edinburgh to Limerick I'm more than happy to fly to Dublin with Aer Lingus and take a train if it means I can avoid having anything whatsoever to do with Rynair... :-) -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM on factory Macs
Frederik Ramm wrote: How would a native Mac application deal with wanting to let the user drag the map and at the same time wanting to let him draw a selection rectangle? Would they have one drag mode and one select mode then, or a modifier key for one of the two actions? A selection tool should auto-scroll the canvas as the selection rectangle approaches the edge of the window (bonus points if the speed of scrolling is proportional to the distance between the mouse and the boundary - selecting up to the edge of the window should scroll slowly, selecting way past the edge of the window should scroll quickly). If there's a separate pan tool then a popular convention is that pressing space will temporarily switch to the pan tool until space is released. Unfortunately the standard Preview.app only implements the second behaviour, but if you have access to a copy of Photoshop then that's probably the best model to copy. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Teleatlas file format
Alilo wrote: Does any one know what file format or database Teleatlas/navteq uses for the maps they are selling to their clients? I don't know about NavTeq, but Tele Atlas data is available in GDF, RMF, Oracle, and Shapefiles. Is there a sample file somwhere? I searched and didn't find any. If you google for multinet shapefile you'll find the table definitions for the shapefile data (the geometry is just points, polylines, and polygons). -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] Progressing OSM to a new data Licence regime
[EMAIL PROTECTED] wrote: This is Parallel Distribution. We (the cc-licences mailing list) discussed it during the CC 3.0 public review. My personal opinion is that it is not a good idea because there is so much room for mischief in it. Personally I feel this is a good step forward from the current licence; it allows the OSM data to be used more widely, and doesn't sacrifice the ability to get back useful improvements to the data. Rather than adding the complexity and potential for locking people out that parallel distribution introduces, and the burden of maintaining it for re-distributors, it is better to simply prohibit technological protection measures being added by anyone other than the end user of the data when they install the previously unprotected data onto their own devices. I'm not sure what you are saying here, but the situation I had in mind is that I work on some commercial software that would like to use OSM data. To do that we would need to pre-process OSM data into our own proprietary format - which involves lossy compression, encryption, building extra meta-data like routing tables, etc. I would like to be able convert OSM data into this format, use it in our app, and make available a reference copy of the snapshot we started from. I'm hoping the intent of 4.6 was to ensure that if OSM went away, and our proprietary map was the only copy of the database in existence, we would have to make the raw .osm available to the world (which is good, IMO). I don't really want to have to make our app accept .osm data as input, since it would be unusable (being able to pre-process at runtime isn't feasible: the USA takes about 2 days prep on a 2Ghz quad-core Mac Pro, so we can't ask someone on an 800Mhz iBook to wait a week...). I don't really want to have to de-compress our copy of the data into .osm format, since I don't think it would be very useful to OSM (we could certainly do it, but since the compression is lossy it would produce a bunch of nodes in different positions and so couldn't be diff'd against OSM to identify changes or confirm there are none). However I would like to be able to let end-users flag up bugs/make changes to map data, which we could feed back into OSM somehow. I think this is a good model, since it benefits all parties: our app gets to use OSM data, our users get to see OSM data, and OSM gets back useful changes. The proposed licence looks like a really good model for geodata to me, as it understands that there are two goals - to encourage wide-spread useage of the data (even commercial use), and to pull back useful changes (and they have to be useful: having someone send back node X is now at 51.12 is pointless when the real OSM data puts node X at 51.1200345). -dair (irrespective of the final licence, I'd like to thank the OSMF and everyone involved in drawing this up - it is really encouraging to see the amount of effort that has gone into this) ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] OSM needs a measure for completeness
Chris Morley wrote: I have started a new thread with a measure for completeness in the title because this is an important topic for OSM. But the response to the recent posts quoted above, and my raising of it last July, has been only luke-warm. I also think completeness is a very important idea - it's false to think that a map is ever going to be complete, but I don't think it's a good answer to say it can't be done. There are places in OSM where there is no data; these are obviously incomplete. Equally there are places in where the data is at least as good as any other map (bits of London say), subject to our data model (no house numbers, say). I wonder whether this is because completeness is associated in people's minds too closely with verification. As Andy has describes it in the (incomplete) quote above, verification involves individual accountability - I personally accept responsibility for the accuracy of this data. I don't think you accept responsibility for it in the sense of liability in case of mistakes, but as soon you as you enter some data into OSM you do accept some responsibility for it. You're responsible for ensuring that it bears some relationship to reality, that it didn't come from an illegal source, etc. As is the case for all other mapping information, an assertion of completeness should only imply the best endeavours of the contributor, not a guarantee of 100% correctness. If you have ridden round a housing estate systematically and collected all the required information, you can reasonably say the area covered is complete. With this understanding, completeness would become part of routine mapping. It would encourage a systematic approach and the collection of any missed information. Absolutely. I would be very happy if there was some way I could give a simple badge (or a score, 1-5, where 1 is empty and 5 is complete), to some area to indicate how done I thought it was. Both to myself as a way to keep track of what's next, but also so that other mappers can see just how much there is to do. A possible detailed approach is as follows. A completeness boundary would be modelled on coastline: it would enclose an area, but would consist of many (ordinary) ways, with the completed area on the right. They would be tagged with one (or possibly more) definitions of completeness like major roads, public roads, public paths, which would be defined on a wiki page. Boundary ways would be moved or added on a day-to-day basis by anybody with local knowledge. An area might even have holes in it. Somebody would provide an overview map showing completed areas, and its animation would feature in most presentations on OSM. I was thinking of a simpler model - each OSM account gets to define a list of bounding circles, and a 1-5 completeness rating for each circle. Circles rather than boxes, because completeness is by definition a fuzzy subject. Rather than trying to exactly cover the world with areas that are done/not done, it'd be better to just drop some approximate circles to cover smallish areas. These will all overlap and generally look a bit of a mess, but I think could be rendered in a way that would give you a sense of completeness in some area and demonstrate progress. E.g., at this point in time the areas that are complete should have more priority when rendering a zoomed out view - everyone knows that London will have lots of little holes in it, but in general most of the circles in there will be complete. When you zoom in then the incomplete areas become more important, so by the time you're at town/village level you want to be able to see which suburbs still need work to do. The only difficult bit is setting up the database to manage this information. I think it would be better done as part of the OSM user accounts, rather than in the OSM database, since I think putting it in the real data encourages us to try and over-specify something that's always going to be ambiguous. Periodically some software pulls all that information out and renders a map of it, or sends a message to any users with obvious contradictions (two circles share more than 75% of their area and their ratings are too far apart, or similar). -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM needs a measure for completeness
Frederik Ramm wrote: There are places in OSM where there is no data; these are obviously incomplete. How would you know ;-) there are places which are complete with nothing on them! Good point! Which makes it all the more important to have a mechanism for marking it as such, if only to reduce the number of people who make pointless trips to the middle of nowhere to confirm there's nothing there... -dair (although given enough pointless trips, you would create a de-facto footpath - problem solved! ;-) ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
