[OSM-talk] AND of India is not aligned with coastlines
I don't know much about AND (Automotive Navigation Data, or AND Data :-)), but it seems kind of horrible in Mumbai. It's great to have data, but won't this be a bad thing for Openstreetmap rather than a good thing? Roads are off a couple of houndred meters. http://openstreetmap.org/?lat=19.18397lon=72.8301zoom=16layers=B0FT Water features don't match sattelite images or PGS coastlines: http://openstreetmap.org/?lat=19.15627lon=72.82369zoom=16layers=B0FT Roads are split up in ways with a small number of segments at every intersection, for no apparent reason -- /emj ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] AND of India is not aligned with coastlines
Erik Johansson wrote: I don't know much about AND (Automotive Navigation Data, or AND Data :-)), but it seems kind of horrible in Mumbai. It's great to have data, but won't this be a bad thing for Openstreetmap rather than a good thing? Roads are off a couple of houndred meters. http://openstreetmap.org/?lat=19.18397lon=72.8301zoom=16layers=B0FT Water features don't match sattelite images or PGS coastlines: http://openstreetmap.org/?lat=19.15627lon=72.82369zoom=16layers=B0FT Roads are split up in ways with a small number of segments at every intersection, for no apparent reason makes it simpler for routing systems ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] How to rollback the edits a new user made by mistake
Hello, yesterday I noticed some bad edits in a zone I'm mapping. I contacted the author (Israfil) and he promptly answered saying that it was a mistake, not knowing that it was editing the real map. Some are new lines: http://www.openstreetmap.org/?lat=43.5049lon=11.2177zoom=14layers=0BFT Other are moved points: http://www.openstreetmap.org/?lat=43.53109lon=11.14862zoom=15layers=0BFT Because I (nor him) can say for sure where are the bad edits, is it possible to revert all the edits made by the Israfil user till yesterday? -- Niccolo Rigacci Firenze - Italy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Potlatch 0.9a
Hi! Thanks for the update! Just got an issue with the new feature. Its really dangerous to be able to shift whole ways that easy. What happens is I accidently moved a large lake and then polatch bugged out due to memory issues. When logged back in, the lake where gone. Now I dont know how to fix this lake... do I need to redraw it? I am reluctant to use the new Potlatch due to this bug... :( /Axel 11 maj 2008 kl. 22.35 skrev Richard Fairhurst: Hi all, I didn't post about 0.9 here but naturally some of you have discovered the changes already... so here's a belated 0.9a update. First of all, as already noted, you can now drag whole ways. So that you don't accidentally drag them, as of 0.9a, you need to click, _hold_ for a very short while, then drag. (You don't need to hold if you'd previously selected the way.) Secondly, there's a generic undo button at the bottom left (or press Z). This is very much a first stab at it: there are a couple of little gremlins still to iron out, and a few things that it won’t undo (such as anything involving relations). If there's anything you spot that needs fixing, let me know. If you find that the map data is obscuring the background (whether it be Yahoo, OAM, NPE or whatever), you can now engage Caps Lock to dim the data. Plus there's the usual range of little tweaks and fixes. cheers Richard ___ 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] Unknown road classifications
On Sun, 11 May 2008, 80n wrote: highway=road This is suitably vague, but has a clear enough meaning. Ah, ok - does this get rendered? (It isn't on Map_Features - maybe it should be). - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
On Sun, 11 May 2008, Jeffrey Martin wrote: Did we ever decide what to do when a road continues but we didn't continue down the road? I tend to do fixme=Road continues or fixme=Footway continues. Although to be honest, in most cases for roads I either follow them as far as they go (when I am doing real OSM surveying), or I am just collecting a track as I drive on some other business so I don't get any detail other than the road's position (and thus won't know if the road continues when I review the track later). - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
On Sun, May 11, 2008 at 12:37 PM, Jeffrey Martin [EMAIL PROTECTED] wrote: Did we ever decide what to do when a road continues but we didn't continue down the road? I can't speak for the other 33,000 contributors, but I (and a few others I know of) simply use isolated nodes as a kind of ellipsis. *** * * * It's quick and fairly obvious to the next mapper, but not exactly bulletproof. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
On 12/05/2008 09:38, Steve Hill wrote: On Sun, 11 May 2008, Jeffrey Martin wrote: Did we ever decide what to do when a road continues but we didn't continue down the road? I tend to do fixme=Road continues or fixme=Footway continues. I put name=whatever (tbc) so it is clear to someone looking at the rendered map that there is something incomplete. Although to be honest, in most cases for roads I either follow them as far as they go (when I am doing real OSM surveying), or I am just collecting a track as I drive on some other business so I don't get any detail other than the road's position (and thus won't know if the road continues when I review the track later). You've got to stop somewhere - not all roads are dead ends and it is impossible to do a settlement of 20,000 people in one session - and putting in stub ends of bits you know aren't going to be done at least gives a clue that there is more there (and that you know there is more there). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
Back when I started OSMing, I came across the tag 'complete=no', so this is what I tend to use On Mon, May 12, 2008 at 6:38 PM, Steve Hill [EMAIL PROTECTED] wrote: On Sun, 11 May 2008, Jeffrey Martin wrote: Did we ever decide what to do when a road continues but we didn't continue down the road? I tend to do fixme=Road continues or fixme=Footway continues. Although to be honest, in most cases for roads I either follow them as far as they go (when I am doing real OSM surveying), or I am just collecting a track as I drive on some other business so I don't get any detail other than the road's position (and thus won't know if the road continues when I review the track later). - Steve xmpp:[EMAIL PROTECTED] [EMAIL PROTECTED] sip:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ 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] Potlatch 0.9a
Axel von Matern wrote: Just got an issue with the new feature. Its really dangerous to be able to shift whole ways that easy. That should be fixed in 0.9a - it's more reluctant to move ways than 0.9 was. What happens is I accidently moved a large lake and then polatch bugged out due to memory issues. When logged back in, the lake where gone. Now I dont know how to fix this lake... do I need to redraw it? You can undelete ways by pressing 'U'. Any ways that have been deleted will show up as red, locked ways - to undelete one, just unlock it by clicking the little padlock symbol. Failing that, if you post where the lake was, I'm sure someone here can have a go. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
On Mon, May 12, 2008 at 9:31 AM, Steve Hill [EMAIL PROTECTED] wrote: On Sun, 11 May 2008, 80n wrote: highway=road This is suitably vague, but has a clear enough meaning. Ah, ok - does this get rendered? (It isn't on Map_Features - maybe it should be). No. But you are welcome to add it to any of the rendering engines. I believe we are lacking a whole class of tags for vague information. I often find that I want/need to tag something but don't know enough about it to describe it in detail. highway=road is a good example of this. Here's some that I think are/could be useful: building=yes (rendered) landuse=grass (rendered) natural=water (rendered) highway=road (not-rendered) It would be particularly useful if Yahoo tracers were to use highway=road as I'm sure they can rarely tell what kind of road it is from 30,000ft. 80n - Steve xmpp:[EMAIL PROTECTED] [EMAIL PROTECTED] sip:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
I'm grouping a replies to several posts for this topic... On 9 May 2008, at 19:13, Jeffrey Martin wrote: Typos in real words are easier to detect than a mistake in entering a number. In the scenario I was suggesting numbers would only replace words for type tags and users would never see the numbers but would just see words (in their own language) mapped to/from numbers in the database by the editor/viewer software. This somewhere between the ID numbers (set purely by software) and latitude/longitude (which users do not enter directly) and all the other tags, most of which (like name=) require user direct input. From: Jeffrey Martin [EMAIL PROTECTED] Date: 9 May 2008 15:09:39 BDT To: elvin ibbotson [EMAIL PROTECTED], OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] tagging and rendering The rendering should be separate from the data. Marking a hiking trail as an autobahn so it will be a different color or be visible on higher zoom levels I think we all agree is wrong. Provided the data is correct, I don't see a problem with altering the way data is collected and recorded to make it easier for renderers, and those who program them and write the rendering rules. I can see the attraction to the use of numbers for the values of the highway tag. Having a new system that does not use terms that have other meanings can force people to think about the OSM definitions of the values. The UK centric terms have this effect for me. I have to think about what motorway means for the US or Korea in terms of the OSM definition because I have no competing definition of the term motorway in my mind. For me motorway only has an OSM definition. I have today tagged a little country lane in my area as a railway line as well as highway=unclassified, as the free-from tagging system would seem to allow this and I wanted to see how it will be rendered by Mapnik and Osmarender. I'm all for freedom but I think the type of a node or way is (like node ID and latitude/longitude) more fundamental than most tags which would retain user input and the potential to invent new tags. From: Jonathan Bennett [EMAIL PROTECTED] Date: 9 May 2008 19:55:01 BDT To: talk@openstreetmap.org Subject: Re: [OSM-talk] tagging and rendering elvin ibbotson wrote: Things humans read need to be human readable. The database should be read by software and if it can be faster and more efficient using numbers, numbers are what should be used. The best way of proving this would be to come up with your own version of the OSM server stack that used ID numbers internally, while still outputting human-readable tag names. How long do you think it would take you? I don't think we want another server. I can already demonstrate it: I am currently experimenting with binary data downloads for my mobile OSM viewer, mom. I need data for scales from 3 (just coastlines and country boundaries for enormous areas) to scale 15 (almost everything in a limited area) and until there is a binary API the data has to be sourced as XML then parsed to binary. The standard OSM API does not have any level-of-detail filtering so I am using XAPI. To get data for a particular scale I have to make several calls to the XAPI for each feature group (natural, highway, waterway, ...) in turn, and each call takes quite a bit of setting up in the code. If, for example, the feature types were structured using a numerical system such that so that all natural features began with 0, all highways with 1, etc, but everything needed at scales smaller than 5 ended with numbers smaller than 3 (eg. coastlines: 01; trunk roads: 12) I could make a simple call for features less than *3. From: Martijn van Oosterhout [EMAIL PROTECTED] Date: 9 May 2008 19:51:18 BDT To: Jeffrey Martin [EMAIL PROTECTED] Cc: OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] street traits On Fri, May 9, 2008 at 8:30 PM, Jeffrey Martin [EMAIL PROTECTED] wrote: A name for each kind of road in a person's country could be set up as an editor feature. I select mountain road 2 from my list and it fills in the number of lanes, lane size, shoulder size, etc. for me. Strangly enough, JOSM supports this already. Another option might be to have some kind of bot that fills in specific data based on country specific highway tags. I thin you're missing something though. Just because it says highway=motorway doesn't mean it looks identical everywhere. It means what a motorway is in the country its located in. Just determine which types of roads there are (there are about 7 usually, no matter what the country) and then map those to the existing highway tags. All done. If you want to add stuff like lanes/etc go ahead, but for the basics you don't need it. A new thread but more evidence that feature type tagging is fundamental and may need rethinking. ___ talk
Re: [OSM-talk] Unknown road classifications
On Mon, 12 May 2008, 80n wrote: Ah, ok - does this get rendered? (It isn't on Map_Features - maybe it should be). No. But you are welcome to add it to any of the rendering engines. Ok, I'll look into doing so. What is the procedure for adding this sort of thing? Just post a patch on the dev list? It would be particularly useful if Yahoo tracers were to use highway=road as I'm sure they can rarely tell what kind of road it is from 30,000ft. That's exactly what I thought. Also people who are just driving around with a GPS without paying particular attention to the information they are collecting (I am guilty of this since I think it is better to collect _something_ when you're driving on unmapped roads, even if you aren't in a position to collect all the information you would usually need from a full survey). - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] TIGER mapping party
On Thu, May 8, 2008 at 5:26 PM, SteveC [EMAIL PROTECTED] wrote: I and others have been doing a lot of fixing of TIGER data all over the US. There is still a lot to do and Richard has added some really useful features to potlatch to speed it up. I was thinking of running a TIGER mapping party. Basically just all sit in a room fixing up TIGER and chatting, maybe beer and pizza provided. People could also participate remotely. Thoughts? Only if we post prominent health warnings. I started doing some TIGER-fixup yesterday in the middle of nowhere in the Mid-West, and it's pretty addictive. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On 12/05/2008 11:59, Andy Robinson (blackadder-lists) wrote: Posted to talk and dev This post really follows on from my consideration of Completeness metrics. A number of experienced OSMers who have mapped out there areas have either contacted me directly or posted through the lists about areas of OSM that are essentially complete, at least as complete as you would expect from a conventional on-line map or better. ... I've raised this a number of times in the past and have been thinking about it recently - to the point I was thinking about implementing something. Here is what I was going to do: 1. use a set of ways like coastline (i.e. with an on the right rule, because they'd be too long as one way), to define areas of completeness. By definition, coastline would form one boundary. 2. Render these plus coastline to a new set of tiles (possibly only at one zoom level, say 13 or 14) so that complete areas are transparent and incomplete areas are semi transparent red, say. Use the ocean tiles database to avoid putting red over all areas of sea. 3. Present these tiles as a layer. For other zooms either combine or divide, or sample, or simply rescale in the browser - the edges need only be quite coarse. I felt this leveraged most from the tools we already have so would be the most straightforward to implement. I was going to have only one measure of complete, that is the surveyor asserts that all publicly-accessible roads are present, with names for all except for those impossible to determine and when that is indicated, and all key points of interest from a limited set: schools, pubs, places of worship; and any railways and significant watercourses. I think it would be confusing for a consumer to have lots of variations in what complete means - just an indicator to say you can't really trust this area yet would be simple. However, since the boundaries can be tagged, there would not be any problem about expanding this for internal use to cover degrees of completeness. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
I don't think we want another server. I can already demonstrate it: I am currently experimenting with binary data downloads for my mobile OSM viewer, mom http://mom.poco.org.uk/. I need data for scales from 3 (just coastlines and country boundaries for enormous areas) to scale 15 (almost everything in a limited area) and until there is a binary API the data has to be sourced as XML then parsed to binary. The standard OSM API does not have any level-of-detail filtering so I am using XAPI. To get data for a particular scale I have to make several calls to the XAPI for each feature group (natural, highway, waterway, ...) in turn, and each call takes quite a bit of setting up in the code. If, for example, the feature types were structured using a numerical system such that so that all natural features began with 0, all highways with 1, etc, but everything needed at scales smaller than 5 ended with numbers smaller than 3 (eg. coastlines: 01; trunk roads: 12) I could make a simple call for features less than *3. At some point there is still going to have to be a map between the freeform tags and your numbering scheme.. your example makes me think you simply want someone else to implement and maintain it so your application becomes easier to code. Have you considered processing the Mapnik or Osmarender style rules to decide what to include/exclude at each scale? -- 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] tagging and rendering
On Monday 12 May 2008 11:50:15 elvin ibbotson wrote: If, for example, the feature types were structured using a numerical system such that so that all natural features began with 0, all highways with 1, etc, but everything needed at scales smaller than 5 ended with numbers smaller than 3 (eg. coastlines: 01; trunk roads: 12) I could make a simple call for features less than *3. Like already pointed out before: This only works if your idea of important is the same as the idea of important of the ones that did the initial ordering. However for a motorist a motorway is the most important road, for a cyclist a cycleway is the most important road and for a canal boater roads are not important at all. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
On Friday 09 May 2008 11:27:21 elvin ibbotson wrote: Much debate centres around the way features are tagged and how they are rendered (for example recent discussion of golf course tagging, the term 'highway', rendering power lines,...) and it seems that much of this is inextricably involved with the OSM data itself. I wondered if it was time, while OSM is still relatively young and before it becomes too ossified and institutionalised, for the approach to be reviewed. My own thoughts, for what they are worth, are that the data structure should be language/locale agnostic. For example, ways could have a numeric type field with, hypothetically, 10-19 being used for roads. In this scenario 11 might be a UK motorway, an Italian autostrada or an American interstate, while 19 might be a rough track (10 being reserved for some not-yet-invented super highway, after all some of us were here before motorways). The editors used to input data (Potlatch, JOSM, whatever) would hide this structured data from the user and translate it to/from human language. One immediate advantage is that a German user could tag an autobahn rather than a motorway and global users would not have to use language clearly derived from the British motorway/trunk road/A/B (and little-known C) road classification system. Instead, local nomenclature would be mapped (no pun intended) to the underlying data structure by the local edition of the editor. Highways are an obvious example we are all familiar with, but the principle would apply to all feature types. Places of worship could be mapped as cathedrals, churches, chapels, etc in Britain or as mosques, temples, shrines, whatever in the east. Problem you are trying to solve: Discussion about tag names Proposed solution: Make tags numerical and have translations from numbers to names for multiple languages. Probable effect: The same discussion about the translations as before about the tag names, but now multiplied by the number of supported languages. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Potlatch 0.9a
Hi! The problems seem to get more bizarre... on my frontend I get a huge, fat way covering the area. Tried to kill it. Also tried to press undelete with no luck. If you got the time to check out whats happening, its here: http://www.openstreetmap.org/edit?lat=59.2471lon=18.0506zoom=17 /Axel 12 maj 2008 kl. 10.40 skrev Richard Fairhurst: Axel von Matern wrote: Just got an issue with the new feature. Its really dangerous to be able to shift whole ways that easy. That should be fixed in 0.9a - it's more reluctant to move ways than 0.9 was. What happens is I accidently moved a large lake and then polatch bugged out due to memory issues. When logged back in, the lake where gone. Now I dont know how to fix this lake... do I need to redraw it? You can undelete ways by pressing 'U'. Any ways that have been deleted will show up as red, locked ways - to undelete one, just unlock it by clicking the little padlock symbol. Failing that, if you post where the lake was, I'm sure someone here can have a go. cheers Richard ___ 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] Potlatch 0.9a
In message [EMAIL PROTECTED] Axel von Matern [EMAIL PROTECTED] wrote: The problems seem to get more bizarre... on my frontend I get a huge, fat way covering the area. Tried to kill it. Also tried to press undelete with no luck. If you got the time to check out whats happening, its here: http://www.openstreetmap.org/edit?lat=59.2471lon=18.0506zoom=17 I think the problem is node 263897947 which is part of a waterway in that box, but which was moved over to the other side of the world somehow by you yesterday: http://www.openstreetmap.org/api/0.5/node/263897947/history The vast distance between that point and the rest of the way seems to be confusing the rendering in Potlatch. 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] [tagging] Road crossings proposal - status?
On Thu, 8 May 2008, Brian Quinion wrote: I like this - but would suggest a small change: highway=crossing crossing=zebra|toucan|pelican|... No, get rid of the UK specific classifications of crossing completely - they require too much background knowledge to interpret and are pointless if you have already split out the various properties into separate tags. Where crossing=zebra is explicitly defined (on the wiki?) as a short cut for: highway=crossing crossingcontrol=uncontrolled foot=yes horse=no I'm not a big fan of having many alternative ways of defining exactly the same feature. A better way to implement shortcuts is to have presets in the editors which automatically set the appropriate tags. My feeling is this leaves lots of room for future expansion without breaking backwards compatibility with most of the existing data. What do people think? IMO It just adds lots of redundent data, which massively complicates anything interpretting it (e.g. the renderers). A clean change over to a totally new system would require no more complexity, but would make it possible for the complexity to eventually be reduced since the old tags could gradually be replaced with new ones (or there could be a bulk search/replace, but I know some people are opposed to this). - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Partners sought for cycle routing project
Hi Frederik, Just quickly, I am interested and my employer - www.bioregional.com - could be a partner on the bid. We're using OSM as part of a municipality sustainability project so this would be right up our street. I will talk to the council about getting them on board too. I've copied my work address in - on holiday today - so please reply to that address to take it further. Kind regards, Tom On Sunday 11 May 2008 11:06:37 Frederik Ramm wrote: Hi, I have been approached by the city of Munich, who want to apply for an EU grant to set up and operate a good cycle routing platform based on OSM data. What they currently have is a platform that uses only their own data which they spent (and spend) a lot of time to create and maintain. They have basic road data and have manually added information about the safety, suitability, and green-ness of routes so that you can get a routing that matches your requirements. What they now intend to do is expand this to encompass the rural areas around Munich as well, while at the same time delegating the data maintenance to the community. Of course the whole thing will be developed in a way that can easily be used for any other place (a major selling point for an EU project). They also intend to create incentives and processes for citizens improve the data. This will probably start with finding out (from their previous experience) what data you need to do proper bike routing, and then analyzing in how far this is already present in OSM, and where not, create/improve tools for people to see where the data is missing and fix it. Then there'll be the development of the routing platform, perhaps based on pgrouting, and then they'll want to set up processes for people to work with the data, e.g. also have a feedback loop into the planning offices so that they know where bottlenecks are and so on. It is not yet exactly clear what the plan is, but they are really keen on not only taking OSM data but also working with the OSM community and feeding everything back to OSM. Munich has recently been in the press for ditching Windows and switching all of the administration IT over to Linux, so they're probably the largest public entity in Germany to have seen the light of free software (and free data now as well). They're looking at a project duration of up to three years, and want to request appropriate funding from the EU under the IEE programme which, among others, has funds available for increasing the use of cycling. The project application has all the right keywords to go down well with the EU (application deadline is 20th June, but the decision will only be made in late 2008), but there's one catch: Any successful EU project needs to have a number of partners in different EU countries, and that's why I am writing this post: Munich doesn't yet have enough partners to get this through. Possible partners include city or regional administrations, cycle associations, even commercial entities like publishers who have an interest. Munich would be the project lead, doing the deals with the EU, but since the project isn't that specific yet, partners will certainly have a say and their wishes be accommodated. Partners will get their share of the money if the project is accepted, and will be expected to co-operate in finalizing the proposal. As an example, a good partner would be a city administration that wants to roll out cycle routing locally, or an administration that wants to create cycle maps, or someone who intends to use the data and put it on mobile navigation devices, or even a public transport entity that intends to combine cycle routing with their traffice schedules or something like that. If anyone is interested, or has an idea about whom we should contact, please tell me. With roughly six weeks left until application deadline, we need partners who are flexible - someone who first has to be convinced that OSM is good would probably be too slow. (If it doesn't work out this year then they intend to apply next year but I guess until then OSM will have done all the work on its own.) We'd be especially happy to find partners in Eastern Europe (it seems that these make funding a project more attractive to the EU), but anyone else outside Germany is also fine. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] tag boundary=national_park depreciated or not ?
The tag boundary=national_park is listed in both these pages : http://wiki.openstreetmap.org/index.php/Deprecated_features http://wiki.openstreetmap.org/index.php/Map_Features#Boundary I don't think this is ok. I searched to an explanation either for the introduction of the tag and the depreciation of the tag but found nothing. tagwatch indicate some uses of this tag. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Allan wrote: | On Sun, May 11, 2008 at 12:37 PM, Jeffrey Martin [EMAIL PROTECTED] wrote: | | Did we ever decide what to do when a road continues but | we didn't continue down the road? | | I can't speak for the other 33,000 contributors, but I (and a few | others I know of) simply use isolated nodes as a kind of ellipsis. | | *** * * * | | It's quick and fairly obvious to the next mapper, but not exactly bulletproof. It's cute, but not easily searchable, unless you want to tag the 3 nodes with something (which would be a really bad idea); it's had to render from (unless you want the ellipsis style rendering, and can cope with rendering all unconnected untagged nodes, and don't care that the size of ellipsis is dependant on zoom level). So we have a choice of: FIXME=incomplete fixme=Road continues name=[whatever] (tbc) towards=[name of place] complete=no Personally I think that FIXME should be a free text description, so I'm not in favour of the first 2 as something to base rendering on. I really don't like adding semantic stuff to the name tag - what if you don't collect the name, or the road doesn't have a name? What if there is a real road out there somewhere that actually has (tbc) in it's name? I really love the illustrated rendering of towards=, but I might not know where the road goes, just that it starts here. I'd vote for complete=no, and rendering it with an arrow on the unconnected end of the way. Sometimes, e.g. if you pass under a bridge, but haven't gone back to pass over it, you may have a way with arrows on both ends. That is fine. I'd allow and render towards=[name of place], but that get's confusing in the 2 ended passing under a bridge case. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKFXmz+aYVHdncI0RAp7lAKD3f/elsoejxcg1XLMHIDZTQ9uGzgCfVNBS 9gqIcL6XBOInRCYGK5pBwKQ= =za0/ -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
On Monday 12 May 2008 15:36:35 Robert (Jamie) Munro wrote: Andy Allan wrote: | On Sun, May 11, 2008 at 12:37 PM, Jeffrey Martin [EMAIL PROTECTED] wrote: | Did we ever decide what to do when a road continues but | we didn't continue down the road? | | I can't speak for the other 33,000 contributors, but I (and a few | others I know of) simply use isolated nodes as a kind of ellipsis. | | *** * * * | | It's quick and fairly obvious to the next mapper, but not exactly bulletproof. It's cute, but not easily searchable, unless you want to tag the 3 nodes with something (which would be a really bad idea); it's had to render from (unless you want the ellipsis style rendering, and can cope with rendering all unconnected untagged nodes, and don't care that the size of ellipsis is dependant on zoom level). So we have a choice of: FIXME=incomplete fixme=Road continues name=[whatever] (tbc) towards=[name of place] complete=no Personally I think that FIXME should be a free text description, so I'm not in favour of the first 2 as something to base rendering on. I really don't like adding semantic stuff to the name tag - what if you don't collect the name, or the road doesn't have a name? What if there is a real road out there somewhere that actually has (tbc) in it's name? I really love the illustrated rendering of towards=, but I might not know where the road goes, just that it starts here. I'd vote for complete=no, and rendering it with an arrow on the unconnected end of the way. Sometimes, e.g. if you pass under a bridge, but haven't gone back to pass over it, you may have a way with arrows on both ends. That is fine. I'd allow and render towards=[name of place], but that get's confusing in the 2 ended passing under a bridge case. This sounds a very sensible way of doing it. I've seen all variations on (in)complete=yes/not/true/false so it would be nice to cater for all of them though I agree that complete=no is probably the best. So any unconnected end of a road tagged with this would have an arrow or perhaps the last segment on the unconnected end could be rendered with a dashed style. It should be obvious to person looking at a map of, say, a town centre that those short roads coming off the high street aren't necessarily short but simply aren't completely mapped yet. This shall have to be documented as to exactly what the complete tag means since I wouldn't be surprised if some people are using it simply as a form of FIXME, as a reminder to themselves that _some_ aspect of the road hasn't been mapped completely yet (e.g. specific taggings) rather than the specific meaning we're applying to it now. The most sensible place would probably be http://wiki.openstreetmap.org/index.php/Key:complete. Matt Williams signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
I like this - but would suggest a small change: highway=crossing crossing=zebra|toucan|pelican|... No, get rid of the UK specific classifications of crossing completely - they require too much background knowledge to interpret and are pointless if you have already split out the various properties into separate tags. OK - but this means that even for the simple cases you have to enter 4 times as many tags. People are lazy (well I certainly am!) and tend to use the easier method - which means people stick with the existing solution and ignore the new method. I'm not a big fan of having many alternative ways of defining exactly the same feature. A better way to implement shortcuts is to have presets in the editors which automatically set the appropriate tags. Implementing presets for this in the editor is a viable alternative. But they need to be implemented in all editors - which could be tricky? Presets could also be implemented centrally server side as part of the 0.6 api change - i.e. an uploaded tag of crossing=zebra|toucan|pelican|... could be 'fixed' on the server and returned back to the client for display (I'm sure almost everyone will absolutely hate this idea!) My feeling is this leaves lots of room for future expansion without breaking backwards compatibility with most of the existing data. What do people think? IMO It just adds lots of redundent data, which massively complicates anything interpretting it (e.g. the renderers). A clean change over to a totally new system would require no more complexity, but would make it possible for the complexity to eventually be reduced since the old tags could gradually be replaced with new ones (or there could be a bulk search/replace, but I know some people are opposed to this). As far as I can see the choice is either to make the renderers or the editors work hard :-) Unfortunately the only centralised location in the current system is the database and I suspect most people will not be happy with the DB changing the data any more than mass search and replace. -- Brian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Limitations of renderers
I have been following with interest the thread on tagging and rendering, and would like to make a slight jump to comment on the inherent limitations for rendering the results. Whilst I do not wish to stifle the use of a wide-ranging tag-set, and applaud the attempts by folk to get agreement on track surface types, variations in access to highways, types of cycle paths, climbing route grades, types of aerial runways/chairlifts, and deeper and deeper landuse classifications, it should be remembered that there is a limit to the human eye's ability to distinguish between similar colours or linestyles in maps and graphical outputs. There is already a problem on the mapnik slippy map in distinguishing between the green tones employed for various landuse types already in play. Similarly, there is an ever increasing proliferation of linestyles being employed to try to map the variations in types of way in different situations. For instance, are you aware of the 7 different styles of purple line used to distinguish admin boundary types on the mapnik layer? So, my point is that if you should reach agreement/concensus on new/deeper tagging, don't automatically think it will be possible to transfer these new flavours to the standard renderers (osmarender or mapnik). In the last couple of days I have had requests to render to the mapnik layer natural=cliff and historic=citywalls, and have seen a talk request for rendering nature reserves a second way to incorporate loacations that are aprt of wholly water-based (at the moment it is a green fill with NR overprint). Now there is nothing wrong with any of those requests, but it just adds further complexity to the range of linestyles and fills that have to be in place, and be visually distinguishable, and keyed in the map legend, etc. Some of the examples listed in para 2 are actually better addressed by specific render cases (a bike map, piste map, climbing map for example for some). I imagine these alternate renders will have to become even more abundant. As folk try to map in depth in their particular field of interest they will need to develop in parallel appropriate rendering styles/outputs (as has very successfully happened with cycle interests already). Anyone wanting to read further on graphical symbology and limitations should seek out some of the seminal texts that have been produced by authors such as Bertin, Tufte and Krygier. Cheers STEVE Steve Chilton, Learning Support Fellow Learning and Technical Support Unit Manager School of Health and Social Sciences Middlesex University phone/fax: 020 8411 5355 email: [EMAIL PROTECTED] http://www.mdx.ac.uk/schools/hssc/staff/profiles/technical/chiltons.asp Chair of the Society of Cartographers: http://www.soc.org.uk/ SoC conference 2008: http://www.abdn.ac.uk/cartographers08/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Limitations of renderers
On 12/05/2008 16:30, Steve Chilton wrote: I have been following with interest the thread on tagging and rendering, and would like to make a slight jump to comment on the inherent limitations for rendering the results. You're quite right of course, but equally there are other reasons to distinguish items even if they are actually rendered the same (I rather think some of the subtle variations of green could in fact all be one green in many cases). Also, there is a third dimension on electronic maps - turning elements and/or layers on and off - which we don't make a whole lot of use of at the moment on our renderers because we don't have the technology just yet. There's also a difference between adding more detail (e.g. cliffs, which seems a natural to be on the map) and trying to distinguish subtly different variations on a theme (kinds of woodland, grass vs park vs nature reserve vs recreation ground vs village green etc). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
David Earl wrote: Here is what I was going to do: 1. use a set of ways like coastline (i.e. with an on the right rule, because they'd be too long as one way), to define areas of completeness. By definition, coastline would form one boundary. 2. Render these plus coastline to a new set of tiles (possibly only at one zoom level, say 13 or 14) so that complete areas are transparent and incomplete areas are semi transparent red, say. Use the ocean tiles database to avoid putting red over all areas of sea. 3. Present these tiles as a layer. For other zooms either combine or divide, or sample, or simply rescale in the browser - the edges need only be quite coarse. I felt this leveraged most from the tools we already have so would be the most straightforward to implement. I was going to have only one measure of complete, that is the surveyor asserts that all publicly-accessible roads are present, with names for all except for those impossible to determine and when that is indicated, and all key points of interest from a limited set: schools, pubs, places of worship; and any railways and significant watercourses. I think it would be confusing for a consumer to have lots of variations in what complete means - just an indicator to say you can't really trust this area yet would be simple. However, since the boundaries can be tagged, there would not be any problem about expanding this for internal use to cover degrees of completeness. I think this is the right approach. I prefer the completeness boundary being a tagged way over the predefined squares approach suggested by Andy because: a) Being able to expand the boundary after each session is likely to be a great motivator. I suspect that this progressive taming of the wilderness or making order out of the void is what drives many mappers. b) Applicability to small or irregular areas (route to work?) might encourage more users. c) No additional tools or procedures are need by the mapper. Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. This covers the essential basic requirements for a number of potential applications for example, routing, delivery, estate agents, bus services. The points of interest, etc. are clearly desirable and but may not be always collected. For instance, tracing from arial photos and naming from an out of copyright gazeteer; or imports like TIGER. (Also I'm not sure I collected all of them when I started 2 years ago.) Start basic and have these in a subsequent level. Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
On Monday 12 May 2008, Andy Allan wrote: Oh, I can think of a way. Yep, I can definitely think of some shorthand tags for the most common crossing types. Trouble is, as soon as I mention it, everyone starts uncontrollably ranting. But that's the problem right? That no-one outside the UK understands the tags without carefully looking them up. Suppose some language in a strange country calls oneway residential roads which allows bicycles to go both ways a penguinroad, would you also support a tag highway=penguin? Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On Monday 12 May 2008 18:06:59 Chris Morley wrote: a) Being able to expand the boundary after each session is likely to be a great motivator. I suspect that this progressive taming of the wilderness or making order out of the void is what drives many mappers. b) Applicability to small or irregular areas (route to work?) might encourage more users. Andy was talking about zoom 18 squares, which map less than 100x100m of the real world each at the latitude of London and Amsterdam. This would be sufficiently detailed to do both those things. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Potlatch 0.9a
I can't remove this trans global way. My Potlatch just freez when trying. Can someone give it a try? /Axel 12 maj 2008 kl. 15.26 skrev Tom Hughes: In message [EMAIL PROTECTED] Axel von Matern [EMAIL PROTECTED] wrote: The problems seem to get more bizarre... on my frontend I get a huge, fat way covering the area. Tried to kill it. Also tried to press undelete with no luck. If you got the time to check out whats happening, its here: http://www.openstreetmap.org/edit?lat=59.2471lon=18.0506zoom=17 I think the problem is node 263897947 which is part of a waterway in that box, but which was moved over to the other side of the world somehow by you yesterday: http://www.openstreetmap.org/api/0.5/node/263897947/history The vast distance between that point and the rest of the way seems to be confusing the rendering in Potlatch. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ 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] street traits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey Martin wrote: | Here is my list of traits. | [snip] | pavement Pavement is a dangerous word because in the UK it means sidewalk (footpath), and in the USA it means the road surface. My Mum failed her USA driving theory test because she didn't know this. :-) Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKHaaz+aYVHdncI0RAmOnAKCYFIgMwGpsg26hxpLCyzw93H6figCg21Rd nTqJfFcyehIb2eqUup7zLKQ= =13AL -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
Andy Allan wrote: Seems sensible to me to have a shorthand. So where you have a type of crossing that's for cyclists and pedestrians but not horses nor canoes, and it's controlled by traffic lights (as opposed to not being controlled at all), we could do with a shorthand way to tag it because it's really common ...at least in your corner of the world. And it is vitally important that the renderers make special accomodations just for you. and typing four or five tags every time is tedious Lets compare counts for each method. Zebra crossing: yours: 1 tag other: 1 tag Pelican crossing yours: 1 tag other: 2 tags Toucan crossing yours: 1 tag other: 2 tags Pegasus crossing yours: 1 tag other: 2 to 4 tags, depending on whether it is also a toucan crossing (From wikipedia: If the crossing is to be used by pedestrians and cyclists too, then a parallel toucan crossing is placed next to the pegasus crossing. Does that mean they should really be separate crossing points entirely?) It's hardly four or five tags every time. and lets face it - editors don't support language-neutral presets and Surely preset definitions could be created in various languages, at least for JOSM. it constitutes 0.4% of all the data in the planet *alone* (...transport:space:vehicles:spaceshuttle=no...), Exaggerate much? Ludicrous example aside, it's not as if defining an access tag for a new vehicle requires that it be explicitly applied to every entity in the database... For what it's worth, while I agree completely with Steve Hill, I'd be fine with including the shortcuts just to make Andy happy. It's not like anyone else has to apply or render them... -Alex Mauer hawke ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
80n wrote: highway=road This is suitably vague, but has a clear enough meaning. Isn't a value of unknown in use on several other tags? It is at least on the whole access series of tags (http://wiki.openstreetmap.org/index.php/Key:access) So highway=unknown would make sense to me. -Alex Mauer hawke ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
On Mon, May 12, 2008 at 5:21 PM, Ben Laenen [EMAIL PROTECTED] wrote: On Monday 12 May 2008, Andy Allan wrote: Oh, I can think of a way. Yep, I can definitely think of some shorthand tags for the most common crossing types. Trouble is, as soon as I mention it, everyone starts uncontrollably ranting. But that's the problem right? That no-one outside the UK understands the tags without carefully looking them up. Suppose some language in a strange country calls oneway residential roads which allows bicycles to go both ways a penguinroad, would you also support a tag highway=penguin? Guys, there's several ways to deal with this: 1) Put How do I tag a Toucan crossing? on the wiki and expect users to type in about 4 tags to define each crossing. Similar for How do I tag a Penguin Crossing?. Tell all those lazy mappers to develop some work ethic dammit. 2) Add presets to the editors to supply a Toucan Crossing option for users in the UK which correctly adds the tags then reinterprets them and presents them as a toucan crossing. Make sure people in the Antarctic see Penguin Crossing instead. There's about 3 editors in constant use at the moment... I'm sure patches are welcome. 3) Use crossing=toucan, crossing=penguin and have the data consumers who are interested know to look for either. Make them look for the 4 other tags too if they are provided instead. Document on the wiki what each one actually means to make it easier for people writing these applications. 4) Write yourself a tag normaliser script that preprocesses OSM tags to come out with some normal form that you define. For bonus marks make this feature recogniser use a user definable transform file. Update a reference transform regularly from documentation on the wiki, or find some cool way of keeping this updated. This way the normalised OSM file can be used by any data consumer without having to edit that consumer for different crossing names. 5) Convince the OSM community of the need for One True Tagset, and install the feature recogniser in the API with the ultimate tagging system preloaded. At the moment the anti-toucan camp is mostly proposing 1). With a little bit of 2) and 5) thrown in with from what I see very little intention of actually doing anything. The pro-toucan camp is partially implementing 3) for as much as they care to do. Some of us really couldn't care less either way. Frankly, please stop talking about it -- you're not getting anywhere. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] street traits
On Friday 09 May 2008 21:57:51 OJ W wrote: This page *tries* to explain the differences: http://wiki.openstreetmap.org/index.php/Highway I suppose my summary would be something like: Motorway: motor vehicles only, always dual-carriageway, always has good level of emergency features, junctions are always grade-separated with slip-roads/on-ramps Trunk: like motorway, but legally allows non-motorised traffic Primary: a road large enough that you wouldn't dare to cycle on it if you wanted to live. Often dual-carriageway, but with a more sloppy approach to creating junctions. Secondary: goes from somewhere important to somewhere important, with lots of traffic. Don't forget tertiary. While there are only a handful of C class roads in the UK (I believe) local councils seem to flit between defining a number of roads as a C or a U and so for these roads either a tertiary or unclassified (or residential if it's applicable) tag makes sense Personally I use tertiary for roads which, while residential, are obviously through-routes and are used extensively as such. This includes roads which bisect housing estates (see Park Lane/Tempest Avenue at [1] and Stakes Hill Road slightly to the South). I feel this reflects their level of importance with respect to the surrounding roads without incorrectly tagging it as, say, a B-road. I feel this fits well with your definition of a residential road as something you wouldn't use as a through-road, but only as a destination by making tertiary be a residential road you _would_ use as a through road. Matt Williams [1] http://openstreetmap.org/?lat=50.8845lon=-1.01108zoom=15layers=B0FT signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
On Mon, May 12, 2008 at 6:03 PM, Alex Mauer [EMAIL PROTECTED] wrote: Andy Allan wrote: Seems sensible to me to have a shorthand. So where you have a type of crossing that's for cyclists and pedestrians but not horses nor canoes, and it's controlled by traffic lights (as opposed to not being controlled at all), we could do with a shorthand way to tag it because it's really common ...at least in your corner of the world. And it is vitally important that the renderers make special accomodations just for you. You just said that to the one guy who's actually writing rendering rules which use this tag. Well done there. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On Monday 12 May 2008 18:06:59 Chris Morley wrote: Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. I have a different view. I think we should have a leveled scheme from the beginning. I suggest the following: Level 1: All the highways (using OSM lingo) usable by cars within an area are mapped Level 2: All highways are mapped and named Level 3: All highways down to cycleways are mapped (and named if feasible). -- Level 4: Level 3 + all amenities within a given set. Level 5: Level 4 + maybe some other amenities or buildings or whatever we decide. These levels map(!) nicely to how I work myself when I map out an area: start with the roads and streets for the cars, and name them. Then later go back to the area and add the cycleways. Sometimes I map a whole lot of other areas before coming back to map the cycleways. Regarding the levels: I can understand if some people would switch level 2 and 3 and I would be fine with that. When an area reaches level 3, I would say that it is finished for the purpose of finding the way (remember it's Open _Street_Map :-) ). All extra information is a bonus, and necessary for certain types of maps, but for the general user or a router, level 3 should be all that is needed. This covers the essential basic requirements for a number of potential applications for example, routing, delivery, estate agents, bus services. The points of interest, etc. are clearly desirable and but may not be always collected. For instance, tracing from arial photos and naming from an out of copyright gazeteer; or imports like TIGER. (Also I'm not sure I collected all of them when I started 2 years ago.) Start basic and have these in a subsequent level. Yes, but it would be good if we planned for at least some of the subsequent levels right from the start. -Inge Chris ___ 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] Limitations of renderers
David Earl wrote: On 12/05/2008 16:30, Steve Chilton wrote: I have been following with interest the thread on tagging and rendering, and would like to make a slight jump to comment on the inherent limitations for rendering the results. You're quite right of course, but equally there are other reasons to distinguish items even if they are actually rendered the same (I rather think some of the subtle variations of green could in fact all be one green in many cases). Also, there is a third dimension on electronic maps - turning elements and/or layers on and off - which we don't make a whole lot of use of at the moment on our renderers because we don't have the technology just yet. There's also a difference between adding more detail (e.g. cliffs, which seems a natural to be on the map) and trying to distinguish subtly different variations on a theme (kinds of woodland, grass vs park vs nature reserve vs recreation ground vs village green etc). David I think we are trying to put too much stuff into a general purpose map. Kinds of woodland aren't really important for someone who is looking for driving directions, for example. On the other hand, a hiker will probably be very interested about the different conditions of footways. This is one of the reasons Kosmos got started - to let anyone define its own rendering rules and encourage sharing of those rules for specialized maps (cycling, hiking, driving etc.) via the wiki. This way you still have the liberty of tagging things the way you want, without worrying how it would be rendered on the main OSM map. Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
Dave Stubbs wrote: You just said that to the one guy who's actually writing rendering rules which use this tag. Well done there. Yeah, he's free to make use of his shortcuts on his own rendering system. That doesn't make those shortcuts globally useful. -Alex Mauer hawke ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On 12/05/2008 18:06, Inge Wallin wrote: On Monday 12 May 2008 18:06:59 Chris Morley wrote: Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. I have a different view. I think we should have a leveled scheme from the beginning. I suggest the following: Level 1: All the highways (using OSM lingo) usable by cars within an area are mapped Level 2: All highways are mapped and named Level 3: All highways down to cycleways are mapped (and named if feasible). That's a very car-centric view of the world. Why down to cycleways? Who are you to say something usable by a car is more important than something usable by a bike? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
Brian Quinion wrote: The only problems I can see is that because it is centralised it is somewhat out of user control - so maybe it should make sense to pull the list of presets from a wiki page (once a day?) and there would be a small amount of server side load to implement it. That would certainly be do-able. People do need to be aware that exactly what a preset tag sets can change without notice as the wiki is updated, and that the changes will only affect new uploads though. I think some sort of quick marco language would be a bonus for all the editors esp. if they shared a standard format for defining them, although at that point I wonder if an api change is needed - downloading a formatted page from the wiki might be as easy esp. if it was cached by the editor. That could be quite cool. One thing that would be really useful is for the editor to tell me what options could be set for an object, and what their defaults are. I.e. when I set a way to highway=tertiary it can tell me that I can set a name, ref, access restrictions, etc. Maybe ordered by the popularity of the various tags and with tags that are semi-mandatory (such as the name of a residential road) in bold. All that data can be pulled from wiki pages and tagwatch. Sadly my Java skills are nonexistent. :( This might be a viable way of handling some country specific presets too, so pre:de:highway=autoban That would be extremely useful since it would allow us to (more easily) throw away country-specific bits from the real data and move them out to a translation system to make editing easier. TBH regardless of the current discussion I think this would be a nice feature so I'll write it! Neat - I look forward to it! :) -- - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
David Earl wrote: Sent: 12 May 2008 7:10 PM To: [EMAIL PROTECTED] Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools On 12/05/2008 18:06, Inge Wallin wrote: On Monday 12 May 2008 18:06:59 Chris Morley wrote: Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. I have a different view. I think we should have a leveled scheme from the beginning. I suggest the following: Level 1: All the highways (using OSM lingo) usable by cars within an area are mapped Level 2: All highways are mapped and named Level 3: All highways down to cycleways are mapped (and named if feasible). That's a very car-centric view of the world. Why down to cycleways? Who are you to say something usable by a car is more important than something usable by a bike? I was actually going to argue that even the footways should be on. That's why I was going for the tile approach because I felt that building up from little pieces was more logical that an all encompassing area. If you have a few footpaths in your area not completed then its not really complete, whereas small tile can be signed off and holes wouldn't matter, they would just get filled in later as you or someone else gets to them. Cheers Andy David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.23.16/1427 - Release Date: 11/05/2008 1:08 PM ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
Alex Mauer wrote: Isn't a value of unknown in use on several other tags? It is at least on the whole access series of tags (http://wiki.openstreetmap.org/index.php/Key:access) So highway=unknown would make sense to me. Something like road=unknown might make sense, but because the highway tag is used for lots of non-road things, highway=unknown could be talking about any kind of highway, such as a footway. Quite a lot of the time you know it is a road because you drove down it, but you don't necessarily know what class of road it is. -- - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On 12/05/2008 20:02, Andy Robinson (blackadder-lists) wrote: David Earl wrote: Sent: 12 May 2008 7:10 PM To: [EMAIL PROTECTED] Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools On 12/05/2008 18:06, Inge Wallin wrote: On Monday 12 May 2008 18:06:59 Chris Morley wrote: Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. I have a different view. I think we should have a leveled scheme from the beginning. I suggest the following: Level 1: All the highways (using OSM lingo) usable by cars within an area are mapped Level 2: All highways are mapped and named Level 3: All highways down to cycleways are mapped (and named if feasible). That's a very car-centric view of the world. Why down to cycleways? Who are you to say something usable by a car is more important than something usable by a bike? I was actually going to argue that even the footways should be on. That's why I was going for the tile approach because I felt that building up from little pieces was more logical that an all encompassing area. If you have a few footpaths in your area not completed then its not really complete, whereas small tile can be signed off and holes wouldn't matter, they would just get filled in later as you or someone else gets to them. I wasn't being entirely serious. I think it is terribly hard to know whether you have all the footpaths, and I think we'd hardly ever mark anywhere complete if we did that. So I think Inge is right - we need different measures for our own use. But on the public map, all streets with names seems a pretty good achievable and useful thing to show. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
Dave Stubbs wrote: Some of us really couldn't care less either way. Frankly, please stop talking about it -- you're not getting anywhere. Actually, I think some fairly insightful suggestions have been made and it is a useful discussion. You don't _have_ to read this thread if you don't care about it, but I dare say that some of the people who are taking part in the discussion do care. -- - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On Mon, May 12, 2008 at 07:06:20PM +0200, Inge Wallin wrote: Yes, but it would be good if we planned for at least some of the subsequent levels right from the start. I support this idea - I would call them levels as some areas might work completely different. I would call the different completenesses like roadcomplete cyclewaycomplete roadnamecomplete landusecomplete etc ... I have no idea about the granularity but in the end it comes down to a map never containing ALL interesting data but it would be interesting to note which subset it contains or is complete. The completeness is more or less a feeling of the primary mapper of this specific area so it should be taken with a grain of salt i guess. But this information would be interesting for a map bug tracker which could assign higher prioritys to bugs in complete areas or even refuse to accept bugs in incomplete areas. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to h elp provide completeness tools
On Monday 12 May 2008 20:09:41 David Earl wrote: On 12/05/2008 18:06, Inge Wallin wrote: On Monday 12 May 2008 18:06:59 Chris Morley wrote: Starting with a single level of completeness makes sense, but I think it should be public roads, named where feasible. I have a different view. I think we should have a leveled scheme from the beginning. I suggest the following: Level 1: All the highways (using OSM lingo) usable by cars within an area are mapped Level 2: All highways are mapped and named Level 3: All highways down to cycleways are mapped (and named if feasible). That's a very car-centric view of the world. Why down to cycleways? Who are you to say something usable by a car is more important than something usable by a bike? Yes that is car-centric. But more importantly, it is size-centric. The larger roads are mapped first, and then the smaller ones. That's what I mean when I say down to, i.e. going from the bigger sizes down to the smaller ones. And I think you agree that larger roads are more important (in general) and also more prominent in the landscape, even if a lot of people use cycle roads more. And just to make things clearI use my bike almost all of the time when I map. -Inge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to h elp provide completeness tools
On Monday 12 May 2008 21:16:38 David Earl wrote: So I think Inge is right - we need different measures for our own use. But on the public map, all streets with names seems a pretty good achievable and useful thing to show. I don't think it is a good idea to call that just complete. I think it should be made very clear that it is just the road network that is complete and not the map. With the import of the AND data the road network in the Netherlands is mostly complete. Now we often hear: Why do you still need to map more? It is complete with the AND data, isn't it? Having more levels or categories of completeness makes it clear that we are not finished yet after we put the roads in the database. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
Steve Hill wrote: tag is used for lots of non-road things, highway=unknown could be talking about any kind of highway, such as a footway. Quite a lot of the time you know it is a road because you drove down it, but you don't necessarily know what class of road it is. Hmm, I would think that if you're marking it as unknown, you already know it's not a footway (footway is a rather lowest-common-denominator value as pedestrians can go just about anywhere) IMO if it's sufficiently unknown that it will have to be revisited anyway for more accurate classification, marking it as a road rather than a complete unknown isn't really going to be helpful to anyone. I don't think it's a good idea for the highway tag to be used for so many non-road things -- but that's probably a discussion for another time. -Alex Mauer hawke ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
I'm very far from this in Korea, but I would guess in time some parts of the UK will need to be rechecked at some point. How can we make a system for rechecking an area? Maybe the completeness should be retired after a period of time. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM Aware, the state of the current pheromones
Hello, Just a quick update and I'm gone. There's now a light v0 version: V0: one summarized placemark per user at the last known position (very low fat, should work on all machines running Google Earth) v1: the most detailed one (a placemark per node). Without feedback I've stopped pushing world daily v1 on the server (see archives or produce them yourself if you want: it takes one or two minutes to crunch for a big world day on my PC). v2: no placemarks but lines (lighter that v1) There's also a list of live network links on the site ( http://code.google.com/p/osmlab/) If you want to refresh a link manually find the network link in the GE folder, right click, refresh http://www.fxfoo.com/osm/kml/world-minute-v1-networkLink.kml http://www.fxfoo.com/osm/kml/world-day-v0-networkLink.kml http://www.fxfoo.com/osm/kml/world-hour-v0-networkLink.kml http://www.fxfoo.com/osm/kml/world-hour-v2-networkLink.kml http://www.fxfoo.com/osm/kml/france-day-v0-networkLink.kml http://www.fxfoo.com/osm/kml/france-day-v2-networkLink.kml For info the network-links don't have yet the stats summary when clicking on the name of the kml (that individual KMLs have). - I'll make a little pause here, having some OSM mapping to catch and more responsive projects I want to invest my energy into. Nerver-the-less I wonder how much the lack of interest in awareness tools in OSM will have an impact on the holes Ed Parsons predicts: http://www.edparsons.com/?p=609 (Sure the OSM growth is exponential but among which population, only/mainly alpha-geeks?) Anyway, happy mapping ...[] (I'm already gone) francois On Sun, May 11, 2008 at 11:39 PM, François Schnell [EMAIL PROTECTED] wrote: Hello list and fellow mappers. I guess it's my first post here even if I map and follow the list for over a year I think (I'm sometimes on IRC). ant rant I love OSM but I miss a quick and easy way to smell your pheromones guys (ie recent activity around me to spot active mappers, adapt/motivate myself in consequence, have local statistics, eventually monitor/spot 'obvious' 'vandalism'). I think a quick awareness is important for a project like OSM and I'd love to see that aspect more developed/encouraged in the future. For bottom-up emergent systems like a 'simple' anthill or a beehive it's even capital. The anthill is very efficient and well structured (nursery, cemetery,...) not because of a savant top-down architect but mainly because two conditions are met: critical mass (having enough ants) and the quality of the local communications/status between members (the pheromones). So I don't say we're ants-like and OSM is en emergent system but I think it certainly has some bottom-up stuff and a quick local mapping awareness could help. /ant rant Anyway, to fulfill my junkie need for pheromones I've played with the .osc files (change sets) provided here: http://planet.openstreetmap.org/ The current - work in progress - result is here: http://code.google.com/p/osmlab/ http://www.fxfoo.com/osm/kml/ So basically by charming the Python snake I extract informations from the .osc files (minutes, hours and days ) and produce a bunch of kml (for quick and dynamic visualization in Google Earth for example). Before any eventual ant get too excited be aware that: - the kml doesn't show ways, the tool is not intended for mapping or comparing (I think an OSMtoKML tool already exist anyway). I'm just interested in seeing/smelling your current pheromones , that's all ;) - the Hour and Day kml are *big* since I render every node in the first version (either placemarks or lines). On my desktop Core2Duo2.4Ghz/2Go, VistaBox and MacBookLaptop, it's ok (but bellow 2Go I doubt it would be a nice experience. I'll produced a much smaller daily/hourly KML soon for those who don't have a gaming PC (by summarizing nearby nodes) - if you encounter a forbidden access on the latest daily/hourly kml retry in a minute (hours/days are still processed on my Vista desktop and send to the Ubuntu server through my ISP limited upload speed , you shouldn't encounter that with minutes which are processed directly on the server) - generally (yellow, blue, red) stands for (created, modified, deleted) - generally clicking on the name of the KML in GE brings a statistics summary, you also can expand the folder to have more informations - clicking on a placemark gives information about the node and links to the associated user and the OSM map Minutes KMLs should be accessible to every machine. There's also a live world-minute network link here: http://www.fxfoo.com/osm/kml/world-minute-v1-networkLink.kml In Google Earth it will automatically update itself with the latest minute available and you should see the latest mappers activity For developers or power users the command line tool is written in Python and should work on Win/OSX/Linux. If you have some Python notions you should be able to modify/extend the app. to create you
[OSM-talk] Mapping distant objects by triangulation.
I couldn't find the other thread on this topic. How do you map an object, like a tower on top of a mountain, that you don't have access to without expensive survey equipment? My thought is to use a plumb bob to line up the unknown object with some known objects. I would find something like a phone pole between me and the mountain tower. I would move along a road until the pole and the tower line up. Now I have a straight line. Do it again with another strait line and I have two lines to define the location. Would that work? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] tagging and rendering
On 9 May 2008, at 03:30, elvin ibbotson wrote: On 9 May 2008, at 11:05, Dave Stubbs wrote: As far as I see it there is no difference between mapping 11=autobahn, and mapping motorway=autobahn. I think you missed the point. At present we have highway=motorway and I believe a German user would need to use these words. What I suggest but what you're suggesting is that we make it crap for everybody, not just germans more logical might be to have everything in mandarin or spanish or whatever the most spoken language is Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
Hi, I'm very far from this in Korea, but I would guess in time some parts of the UK will need to be rechecked at some point. How can we make a system for rechecking an area? Maybe the completeness should be retired after a period of time. Once we have a few applications in place that get viewed by *many* people, we could just have a button somewhere along the margin of the page that says: I know the area and what I see here looks correct. That would not give us any safety but if, when looking at a part of the map, you knew that within the last 6 months 178 people had clicked on this looks correct then that would perhaps give you at least a warm fuzzy feeling ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Road crossings proposal - status?
On Mon, May 12, 2008 at 7:25 PM, Brian Quinion [EMAIL PROTECTED] wrote: I'll have a go at implementing a local macro system in JOSM and see how well it works then it can be extended to pull from the server if it seems worth having. Well, JOSM already supports preset files which can be loaded over the internet automatically. I made a preset file for NL which used NL descriptions. http://kleptog.org/temp/nl-wegen.xml Not exactly sure how much simpler it could be made. 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] [tagging] Road crossings proposal - status?
On Mon, May 12, 2008 at 7:57 PM, Steve Hill [EMAIL PROTECTED] wrote: Brian Quinion wrote: The only problems I can see is that because it is centralised it is somewhat out of user control - so maybe it should make sense to pull the list of presets from a wiki page (once a day?) and there would be a small amount of server side load to implement it. That would certainly be do-able. People do need to be aware that exactly what a preset tag sets can change without notice as the wiki is updated, and that the changes will only affect new uploads though. You're not really thinking about this in the right way. There's very little point in inserting a filter on API uploads to implement some, by definition, one-way mapping, working off a hacked wiki-scraping. Inevitably that leads to data-loss. The filter should be applied in the other direction, on reads, and at the choice of the consumer. I think some sort of quick marco language would be a bonus for all the editors esp. if they shared a standard format for defining them, although at that point I wonder if an api change is needed - downloading a formatted page from the wiki might be as easy esp. if it was cached by the editor. That could be quite cool. One thing that would be really useful is for the editor to tell me what options could be set for an object, and what their defaults are. I.e. when I set a way to highway=tertiary it can tell me that I can set a name, ref, access restrictions, etc. Maybe ordered by the popularity of the various tags and with tags that are semi-mandatory (such as the name of a residential road) in bold. All that data can be pulled from wiki pages and tagwatch. Sadly my Java skills are nonexistent. :( Much more along the right lines, but seriously guys, web page scraping? If you do this thing, please do it properly. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Users whose contributions are in the public domain
On Sun, May 4, 2008 at 2:21 PM, Ari Torhamo [EMAIL PROTECTED] wrote: su, 2008-05-04 kello 15:40 +0200, Mike Collinson kirjoitti: At 01:33 PM 4/05/2008, Ari Torhamo wrote: la, 2008-05-03 kello 17:39 -0400, Ted Mielczarek kirjoitti: Why else are we contributing this data if not for people to *use* it? I suggest you go and present this breath taking argument to RMS, and we might soon get an updated, more free version of GPL. Ari The GPL works very well as it already allows folks to *use* software with no restriction on what they make with that use. Adding something new to GPL software source code is clearly different from using existing GPL software to do something new. That distinction is far from clear when using collations of facts like OSM data. So a different model is required. The PD argument is a very easy and elegant solution, but it makes some contributors very uncomfortable. The new license being worked on seeks to make a, hopefully, comprehensible distinction for factual data. OK, thanks for explaining this. I was actually just responding to sarcasm that I didn't like, but perhaps I could have been more educated doing it :-) (or perhaps it would be best that we weren't sarcastic to each other at all). For what it's worth, I wasn't being sarcastic, more like exasperated. I hate seeing licensing issues confound useful activities, whether they be software, music, art, or mapping. Seeing people wasting time having a discussion about whether they can legally use something instead of spending that time doing something useful makes me sad. I apologize if I came off as sarcastic, it can be difficult to infer tone over email! Regards, -Ted ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
Freek recently created this image which shows how much of the AND data is untouched: http://www.vanwal.nl/osm/author_density_nl_20080502_full.png(warning 3 MB image). I think the z18 idea is good idea. On Mon, May 12, 2008 at 11:36 PM, David Earl [EMAIL PROTECTED] wrote: On 12/05/2008 21:02, Cartinus wrote: On Monday 12 May 2008 21:16:38 David Earl wrote: So I think Inge is right - we need different measures for our own use. But on the public map, all streets with names seems a pretty good achievable and useful thing to show. I don't think it is a good idea to call that just complete. I think it should be made very clear that it is just the road network that is complete and not the map. Fine. With the import of the AND data the road network in the Netherlands is mostly complete. Now we often hear: Why do you still need to map more? It is complete with the AND data, isn't it? Having more levels or categories of completeness makes it clear that we are not finished yet after we put the roads in the database. I think we are violently agreeing here! David ___ 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] [OSM-dev] Developers requested to help provide completeness tools
On Mon, May 12, 2008 at 8:16 PM, David Earl [EMAIL PROTECTED] wrote: I think it is terribly hard to know whether you have all the footpaths, and I think we'd hardly ever mark anywhere complete if we did that. I think it's terribly hard to know when a map is correct and complete, regardless of what you're considering. In fact, as something I've floated with some people before, I think the idea of completeness is the wrong way round. I think we should be considering where a map is *incomplete*. Think about it. If you are presented with a map of your village and asked whether it's right, it's very unlikely that you know all the roads and all the names and how everything connects and be sure of yourself. But it's quite likely that what you'll spot (if anything) is a mistake or a missing road. I can do this with TIGER stuff for example - I can't tell you if the map is correct, but I can definitely find bits that are definitely wrong. I've been considering what I'd do to Wandsworth and Fulham (my local areas) if someone asked me to mark which areas are correct. I think there's very little value in me doing so, since most roads I've only been down once and hardly likely to check the name from memory. But there's a couple of bits that are definitely wrong, and I can point them out easily. It's just another way of thinking about it, but I think that neutral/wrong is probably more useful than neutral/complete when considering maps. And it certainly cuts out trying to define 'complete', since whichever reason something is wrong (name, connectivity, missingness) it's very easy to state why it's wrong. And rather than more and more being complete (for this, that and the other definition of complete) there'll be fewer and fewer bits that are wrong. Nobody ever looks at a map and remarked how many bits were correct. Nor does any software product keep a list of lines of code that are working. Or it's an 'exception driven' way of considering things. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
On 12/05/2008 22:51, Andy Allan wrote: On Mon, May 12, 2008 at 8:16 PM, David Earl [EMAIL PROTECTED] wrote: I think it is terribly hard to know whether you have all the footpaths, and I think we'd hardly ever mark anywhere complete if we did that. I think it's terribly hard to know when a map is correct and complete, regardless of what you're considering. There will always be some unintentional errors, but I am confident enough of mapping villages and sections of towns systematically to be able to assert that I have completed it to that measure of completeness - that I have visited every street and got every name possible. (But I don't mind using some other word for it if you like, e.g. a confidence level or some such). I think I would have a much harder time being systematic about footpaths, especially the rural ones, so I wouldn't have the same degree of confidence in my mapping of a footpath network. Maybe if that's what I specialised in my confidence would grow, but the concept of junctions where you can note the other routes from from need attention seems a much less well defined concept for footpaths. But the main point about footpaths is that using that as the only measure would be very dispiriting because it would be so hard to complete any reasonable areas to that standard, and completeness at the street level is very useful for lots of purposes that doesn't require footpaths so is worth showing to consumers. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Limitations of renderers
So it might be useful to have a renderer that does everything on request instead of storing large amounts of pregenerated tile images? (i.e. so that the server requirements are no longer proportional to the number of map styles that it serves) If that could be made to work, then everyone could create a load of map layers containing their preferred features - just upload a stylesheet and immediately browse the results on this slippy map... On Mon, May 12, 2008 at 6:57 PM, Igor Brejc [EMAIL PROTECTED] wrote: David Earl wrote: On 12/05/2008 16:30, Steve Chilton wrote: I have been following with interest the thread on tagging and rendering, and would like to make a slight jump to comment on the inherent limitations for rendering the results. You're quite right of course, but equally there are other reasons to distinguish items even if they are actually rendered the same (I rather think some of the subtle variations of green could in fact all be one green in many cases). Also, there is a third dimension on electronic maps - turning elements and/or layers on and off - which we don't make a whole lot of use of at the moment on our renderers because we don't have the technology just yet. There's also a difference between adding more detail (e.g. cliffs, which seems a natural to be on the map) and trying to distinguish subtly different variations on a theme (kinds of woodland, grass vs park vs nature reserve vs recreation ground vs village green etc). David I think we are trying to put too much stuff into a general purpose map. Kinds of woodland aren't really important for someone who is looking for driving directions, for example. On the other hand, a hiker will probably be very interested about the different conditions of footways. This is one of the reasons Kosmos got started - to let anyone define its own rendering rules and encourage sharing of those rules for specialized maps (cycling, hiking, driving etc.) via the wiki. This way you still have the liberty of tagging things the way you want, without worrying how it would be rendered on the main OSM map. Igor -- http://igorbrejc.net ___ 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] Limitations of renderers
Hi, So it might be useful to have a renderer that does everything on request instead of storing large amounts of pregenerated tile images? It's called a WMS server, and I believe Fake Steve C recently had a prototype on his blog. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM Aware, the state of the current pheromones
Hi, just thought this was a lovely, brilliant visualisation of osm usage. Well done, good work! Would love to see some of this in non-kml formats, somehow (google earth doesn't work well for me). Or on the web. (GeoRSS? GML? Worldwind? etc) as an overlay over existing osm maps? tim ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Lohoff schrieb: | On Mon, May 12, 2008 at 07:06:20PM +0200, Inge Wallin wrote: | Yes, but it would be good if we planned for at least some of the subsequent | levels right from the start. | | I support this idea - I would call them levels as some areas might work | completely different. I would call the different completenesses like | | roadcomplete | cyclewaycomplete | roadnamecomplete | landusecomplete | | etc ... I have no idea about the granularity but in the end it comes | down to a map never containing ALL interesting data but it would be | interesting to note which subset it contains or is complete. | | The completeness is more or less a feeling of the primary mapper of | this specific area so it should be taken with a grain of salt i guess. I would like to point out the system Munich, Bremen, and other city-communities use on our wiki to mark their completeness. it's not leveled, just different areas (an not necessarily complete as an indicating scheme). - -- 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 iD8DBQFIKK3gFUbODdpRVDwRAgWOAKCpL+HsiNT53a3U8wHnymX9BWRtXQCgxc8Y tqFo2yOQSvpWbz+9tNr7YPw= =CEPn -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
Andy Allan [mailto:[EMAIL PROTECTED] wrote: Sent: 12 May 2008 10:52 PM To: David Earl Cc: Andy Robinson (blackadder-lists); talk@openstreetmap.org Subject: Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools On Mon, May 12, 2008 at 8:16 PM, David Earl [EMAIL PROTECTED] wrote: I think it is terribly hard to know whether you have all the footpaths, and I think we'd hardly ever mark anywhere complete if we did that. I think it's terribly hard to know when a map is correct and complete, regardless of what you're considering. In fact, as something I've floated with some people before, I think the idea of completeness is the wrong way round. I think we should be considering where a map is *incomplete*. Think about it. If you are presented with a map of your village and asked whether it's right, it's very unlikely that you know all the roads and all the names and how everything connects and be sure of yourself. But it's quite likely that what you'll spot (if anything) is a mistake or a missing road. I can do this with TIGER stuff for example - I can't tell you if the map is correct, but I can definitely find bits that are definitely wrong. Some of us map out an area completely in one go rather than doing it piecemeal. Even if I come across some existing roads in a new area I ignore them and do a new survey so that the whole area makes logical sence to me. That way I can work out where the landuse areas are behind the houses and the extent of school areas etc etc. So for me a reasonable level of completeness is easy to decide and annotate. I accept where many users touch the same area, especially areas with Y! imagery then this approach probably is not workable. Cheers Andy I've been considering what I'd do to Wandsworth and Fulham (my local areas) if someone asked me to mark which areas are correct. I think there's very little value in me doing so, since most roads I've only been down once and hardly likely to check the name from memory. But there's a couple of bits that are definitely wrong, and I can point them out easily. It's just another way of thinking about it, but I think that neutral/wrong is probably more useful than neutral/complete when considering maps. And it certainly cuts out trying to define 'complete', since whichever reason something is wrong (name, connectivity, missingness) it's very easy to state why it's wrong. And rather than more and more being complete (for this, that and the other definition of complete) there'll be fewer and fewer bits that are wrong. Nobody ever looks at a map and remarked how many bits were correct. Nor does any software product keep a list of lines of code that are working. Or it's an 'exception driven' way of considering things. Cheers, Andy No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.23.16/1429 - Release Date: 12/05/2008 6:14 PM ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools
David Earl [mailto:[EMAIL PROTECTED] wrote: Sent: 12 May 2008 11:06 PM To: Andy Allan Cc: Andy Robinson (blackadder-lists); talk@openstreetmap.org Subject: Re: [OSM-talk] [OSM-dev] Developers requested to help provide completeness tools On 12/05/2008 22:51, Andy Allan wrote: On Mon, May 12, 2008 at 8:16 PM, David Earl [EMAIL PROTECTED] wrote: I think it is terribly hard to know whether you have all the footpaths, and I think we'd hardly ever mark anywhere complete if we did that. I think it's terribly hard to know when a map is correct and complete, regardless of what you're considering. There will always be some unintentional errors, but I am confident enough of mapping villages and sections of towns systematically to be able to assert that I have completed it to that measure of completeness - that I have visited every street and got every name possible. (But I don't mind using some other word for it if you like, e.g. a confidence level or some such). +1, I don't mind what words we use either. I think I would have a much harder time being systematic about footpaths, especially the rural ones, so I wouldn't have the same degree of confidence in my mapping of a footpath network. Maybe if that's what I specialised in my confidence would grow, but the concept of junctions where you can note the other routes from from need attention seems a much less well defined concept for footpaths. But the main point about footpaths is that using that as the only measure would be very dispiriting because it would be so hard to complete any reasonable areas to that standard, and completeness at the street level is very useful for lots of purposes that doesn't require footpaths so is worth showing to consumers. So maybe we have a list of all the main way types (highway, waterway etc) and we put a completeness level/confidence level on each one. Too many though and contributors will loose interest. Perhaps just: Roads Cycleways/Bridleways Footways Rivers/Major Streams/Canals Railways Cheers Andy David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help providecompleteness tools
Florian Lohoff wrote: Sent: 12 May 2008 8:29 PM To: Inge Wallin Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] [OSM-dev] Developers requested to help providecompleteness tools On Mon, May 12, 2008 at 07:06:20PM +0200, Inge Wallin wrote: Yes, but it would be good if we planned for at least some of the subsequent levels right from the start. I support this idea - I would call them levels as some areas might work completely different. I would call the different completenesses like roadcomplete cyclewaycomplete roadnamecomplete landusecomplete There is no reason why contributors could not decide what the list should be. It's clear then to everyone what has and has not been mapped and gives the mapper a sense of achievement even if they weren't ever interested in mapping areas for instance. Someone can add that level of completeness later. etc ... I have no idea about the granularity but in the end it comes down to a map never containing ALL interesting data but it would be interesting to note which subset it contains or is complete. The completeness is more or less a feeling of the primary mapper of this specific area so it should be taken with a grain of salt i guess. Yes, Its not a substitute for secondary verification. Cheers Andy But this information would be interesting for a map bug tracker which could assign higher prioritys to bugs in complete areas or even refuse to accept bugs in incomplete areas. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.23.16/1429 - Release Date: 12/05/2008 6:14 PM ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Developers requested to help providecompleteness tools
Jeffrey Martin wrote: Sent: 12 May 2008 9:38 PM Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] [OSM-dev] Developers requested to help providecompleteness tools I'm very far from this in Korea, but I would guess in time some parts of the UK will need to be rechecked at some point. How can we make a system for rechecking an area? Maybe the completeness should be retired after a period of time. Verification is a whole new ballgame. I tried a bit in my local area, going out on foot with the printed OSM map at highest zoom and annotating the missing bits and pieces for addition. It increased the richness of the data considerably but made me realise that there is a second phase that will still add a huge amount of data. Personally I think we have more pressing things to worry about that verification right now. Something perhaps for a year or two hence. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping distant objects by triangulation.
I can give some ideas on this using basic surveying. JOSM measurement tools will let you do the editing too so its not that difficult to get items mapped in this way. Especially useful for descrete objects in an otherwise fairly featureless landscape. Until I get a moment to drop something on the wiki you might check your local library for a copy of Surveying by Bannister and Raymond. The current edition is the 7th however earlier editions cover the basics of elementary surveying as those techniques haven't changed. Older editions can be picked up now and again on ebay for around a fiver. Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:talk- [EMAIL PROTECTED] On Behalf Of Jeffrey Martin Sent: 12 May 2008 9:48 PM To: OSM Talk Subject: [OSM-talk] Mapping distant objects by triangulation. I couldn't find the other thread on this topic. How do you map an object, like a tower on top of a mountain, that you don't have access to without expensive survey equipment? My thought is to use a plumb bob to line up the unknown object with some known objects. I would find something like a phone pole between me and the mountain tower. I would move along a road until the pole and the tower line up. Now I have a straight line. Do it again with another strait line and I have two lines to define the location. Would that work? -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.23.16/1427 - Release Date: 11/05/2008 1:08 PM ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping distant objects by triangulation.
In theory, yes. In practice, maybe. You would find that if you did a third measuring line, it probably wouldn't intersect where the first two did. Small errors at the measuring end cause massive errors at the other end. Even the guys with the specialist measuring equipment working on a building site can have trouble. It's all about levers. If your first two known points are say 100 meters apart, and the object you're trying to measure is 2,000 meters away, a five meter sideways error at this end on one of the points (an easy error with a GPS) would cause a 400 meter variation at the other end. Which means if you want to do this, you need to do the following. 1) More than two lines. Three minimum, more is better. Also come from as wide an angle as possible. 2) Get your two known points as far apart as you can. If your telepone pole is halfway between you and your target, then the errors at the other end are the same as the errors at your end. 3) Make sure you mark the target source as not by GPS (maybe source=triangulation?) Stephen 2008/5/13 Jeffrey Martin [EMAIL PROTECTED]: I couldn't find the other thread on this topic. How do you map an object, like a tower on top of a mountain, that you don't have access to without expensive survey equipment? My thought is to use a plumb bob to line up the unknown object with some known objects. I would find something like a phone pole between me and the mountain tower. I would move along a road until the pole and the tower line up. Now I have a straight line. Do it again with another strait line and I have two lines to define the location. Would that work? -- http://bowlad.com ___ 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-nl] Fiets tracks: automatisch foto's maken....
On Mon, 12 May 2008, Gert Gremmen wrote: Bij de macro kost een compatible (met CHDK) Canon 460 slechts 69 ex. Is dat de goedkoopste beschikbaar? Alleen geen idee hoe 'groothoek' het is. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: [OSM-talk] Partners sought for cycle routing project
On Mon, 12 May 2008, Martijn van Oosterhout wrote: Ik weet niet of mensen hiermee kunnen helpen. Cycle-routing is wat wij willen, maar hebben wij organisaties die mee kunnen tellen? Ik denk persoonlijk dat dit een van de aangrijppunten is om een OSM organisatie een boost te geven, dan wel een groepje mensen de kans kan geven om zich professioneel met OSM bezig te laten houden. ...nadeel is natuurlijk scheve gezichten. (als je begrijpt wat ik bedoel) Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: [OSM-talk] Partners sought for cycle routing project
On Mon, May 12, 2008 3:55 pm, Martijn van Oosterhout wrote: Ik weet niet of mensen hiermee kunnen helpen. Cycle-routing is wat wij willen, maar hebben wij organisaties die mee kunnen tellen? Bedrijven kunnen mee tellen. Ik lees bijv van Martijn P. wel eens dat hij leuke dingen op de todo heeft staan, maar druk natuurlijk. Als een paar van die dingen onder het project kunnen vallen, is er geld voor - en een deadline ;-) vriendelijke groet, cordialmente, Ante ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken....
Ik heb er vanochtend een gehaald, en de hack library laat zich prima Installeren. Nu nog een scriptje kopieren Om elke 5 seconden een foto te maken (endless). Gert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Stefan de Konink Verzonden: maandag 12 mei 2008 13:30 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken On Mon, 12 May 2008, Gert Gremmen wrote: Bij de macro kost een compatible (met CHDK) Canon 460 slechts 69 ex. Is dat de goedkoopste beschikbaar? Alleen geen idee hoe 'groothoek' het is. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken....
On Mon, 12 May 2008, Gert Gremmen wrote: Ik heb er vanochtend een gehaald, en de hack library laat zich prima Installeren. (Klinkt *erg* interessant... zouden we er ook een com port dan iets wat direct GPS kan inladen op kunne hacken?) Nu nog een scriptje kopieren Om elke 5 seconden een foto te maken (endless). Ik zou zeker naar secondes gaan. Op 15km/h praat je toch al over meer dan 4m aan beeld. Wanneer komt die soldeer-meet er? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken....
De snelheid van de camera is niet zo hoog. De meesten hale niet meer dan 1 a 1.5 sec. Verder zij nerwaarschuwingen ivm oververhitten Van de beeldsensor bij volcontinue bedrijf. Ik heb nog geen compoort hack gezien, maar Wel een heleboel refs naar remote contol via usb. Ergens eind deze maand ??? Gert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Stefan de Konink Verzonden: maandag 12 mei 2008 18:14 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken On Mon, 12 May 2008, Gert Gremmen wrote: Ik heb er vanochtend een gehaald, en de hack library laat zich prima Installeren. (Klinkt *erg* interessant... zouden we er ook een com port dan iets wat direct GPS kan inladen op kunne hacken?) Nu nog een scriptje kopieren Om elke 5 seconden een foto te maken (endless). Ik zou zeker naar secondes gaan. Op 15km/h praat je toch al over meer dan 4m aan beeld. Wanneer komt die soldeer-meet er? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken....
Amaryllo, hoe dat zo ??? Gert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Stefan de Konink Verzonden: maandag 12 mei 2008 18:28 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken On Mon, 12 May 2008, Gert Gremmen wrote: De snelheid van de camera is niet zo hoog. De meesten hale niet meer dan 1 a 1.5 sec. Verder zij nerwaarschuwingen ivm oververhitten Van de beeldsensor bij volcontinue bedrijf. Ach... klopt ja. Dagje fietsen in de zon zal zo'n sensor ook niet goed doen... Toch maar een D1MIIIs pakken ;) Ik heb nog geen compoort hack gezien, maar Wel een heleboel refs naar remote contol via usb. Ergens eind deze maand ??? Zouden we in de tussentijd even de banden met Amaryllo moeten aanhalen ;) Ik denk dat die wel geinteresseerd zijn in zo'n 'out of the box' feature. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: Outdoor geekevent (eth0)
Ik ben er vrijwel zeker van dat ik ga, dus ik wil er wel wat mee doen... At Wed, 16 Apr 2008 19:19:16 +0200, Ante Wessels wrote: Uitnodiging, iemand zin om er iets mee te doen? -- Forwarded Message -- Subject: Outdoor geekevent (eth0) Date: Wednesday 16 April 2008 Beste Ante, Ik heb je naam opgepikt aan de hand van je posts op openstreetmap.nl, het duurde even voordat ik je email adres gevonden had, maar bij deze dus. Wellicht had je er al van gehoord, maar wij zijn bezig om van de zomer een outdoor geek event op te zetten met als doel gezellig samen over computers, opensource software, content en unix kletsen. Uiteraard vind ik dat OpenStreetmap hier bij hoort, en dus wil ik je uinodigen op ons irc stekje om een gezellig mee te kletsen om te zien wat we allemaal voor elkaar kunnen betekenen. Het event is buiten, op een grasveld en iedereen dient z'n eigen pc en tent te verzorgen, stroom, internet en andere faciliteiten worden verzorgd door ons, maar aanvullig mogen natuurlijk gewoon meegenomen worden. Mocht je vragen of opmerkingen hebben, laat ze me horen, dan gaan we een antwoord of oplossing zoeken. vr gr Jan Klopper -- ETH0, the proper lanparty http://www.ETH-0.nl irc://irc.eth-0.nl/eth0 --- -- vriendelijke groet, cordialmente, Ante ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fiets tracks: automatisch foto's maken....
On Mon, 12 May 2008, Gert Gremmen wrote: Amaryllo, hoe dat zo ??? Laat die Amaryllo maar USB commando's doorsturen hoor... liefst inclusief GPS coordinaten. De laatste keer dat ik met de Nederlandse en dev persoon uit Azie sprak was open source maken een probleem vanwege de SifrII code. Maar met uitgewerkte feature requests wilden ze altijd wel wat doen. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [talk-au] more copyright stuff
But I think you are right Liz, it is relevant. I believe some osmers collect street names by exception, that is, they compare what a published map says with what street signs say, tick the confirmed ones, and when they see an exception, note it. I think this makes their list a derived work and so is relatively high risk. A demonstrable survey, such as a set of geocoded photos of signs, seems clearly not derived, and so more bulletproof, to me. But then I've done almost none of that kind of survey myself, and consequently have added almost no names, so I suppose I don't have much cred on this. 2c supply now gone... Andrew. Another way to look at this may be, As far as street names go, the actual data collection occurrs when you read the name off the road sign. How you choose to remember this data, in order to edit it into JOSM is anothe matter. You may 1) just remenber it 2) spell it out into a tape recorder 3) photograph it (hopfully with a geotag attached) 4) write it down on a piece of paper or 5) If you happen to already have a piece of paper (say a published map) that has the correct spelling on it then you could just circle this string so as to remember what you read off the street sign. I don't believe that option 5 results in a derived work although you are right that a complete geotagged photo library of all street signs and one way signs etc. would be wonderful, Nick ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [Talk-de] JOSM: Neues Plugin
Christoph Eckert schrieb: ja, fällt mir bei uns in der Gegend auch auf. Allerdings sehe ich sowas nicht zwingend als Fehler. Einer der Autoren von Navit möchte beispielsweise herausbekommen, ob eine Straße innerhalb oder außerhalb einer geschlossenen Ortschaft ist, um beim Routing auf die unterschiedlichen Geschwindigkeiten Rücksicht nehmen zu können. Für solche Fragestellungen ist es IMO günstig, wenn die Straße sich mit dem Landuse schneidet, oder? landuse sagt nur etwas über vorhandene bebauung aus, das ortschild kann gnaz woanders stehen und überhaupt wird sehr oft eine max. geschwindigkeit != 50 angeordnet. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Am Montag, 12. Mai 2008 05:42:13 schrieb Henry Loenwind: Frederik Ramm wrote: dazu, trac genau zu verfolgen, daher danke fuer den Hinweis. Ok, Patch hängt am Ticket. Zunächst erst einmal vielen Dank für eure stete Mühe. Die 632 ist in polygonreichen Gebieten wesentlich besser benutzbar. Die bisherigen Verbesserungen sind für mich schon ein Unterschied wie Tag und Nacht. Wenn jetzt noch die Probleme der nicht-transparenten Layer aus #736 behebt, bzw. die Lösungen einpflegt, dann kann man wieder richtig schön mit josm loslegen. Wie gesagt, draw.rawgps.trianglelines ist bei mir mehr als 10 mal schneller als einfache Linien - und ich verstehe es nicht... Mal in's Blaue hinein vermutet. Die Engines von Grafikkarten bzw. die ansteuernden Treiber sind doch alle auf das Arbeiten mit Dreiecken getrimmt. Deswegen prüfen ja auch viele Benchmarks die Dreiecksfüllrate, Vielleicht ist es im Code so (ohne ihn gesehen zu haben), dass die Linienfunktion darauf beruht, dass die einzelnen Punkte der Linie von der CPU berechnet werden müssen, und diese Punkte zum Zeichnen an die Grafiktreiber übergeben werden, wärend die Dreiecksfunktion direkt an die Treiber gegeben wird, und dieser sie wiederum auch nur zur Berechnung und Darstellung in die GPU schiebt. Mit dieser Erklärung kann ich mir die von dir beobachteten Geschwindigkeitsunterschiede sehr gut vorstellen. Gruß Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] offizielle Bezeichnung von Bundesstraß en/ Autobahnen
Simon Kokolakis schrieb: Ne, also ich finde es sollte kein Kriterium sein, ob der Renderer ein gutes oder schlechtes Ergebnis liefert. Es ist ja mal gut, dass gut und schlecht absolut ist. In diesem sinne: ein schlechtes ergebnis wäre gut. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] rendert uralte Daten?!
Sven Geggus schrieb: Henry Loenwind [EMAIL PROTECTED] wrote: Das passiert aber leider sehr einfach. z.B. Rechner runterfahren, 2 Wochen in Urlaub gehen, tah starten. Schwupp, alte Daten im Upload... *argh* Dann sollte man die scripten so anpassen, dass sie nur Dinge hochladen, die zeitnah gerendert wurden. Na (fränggisch), das wäre auch nicht viel besser. Schaut euch doch mal an, das der Build-Service-Scheduler von openSUSE das macht (vor einiger zeit hatte ich schon einmal darauf hingewiesen). Stichworte: Hochrechnen, wie lang ein tile normalerweise unterwegs ist. Wird diese zeit überschritten, kann das tile neu vergeben werden. Der scheduler muss sich natürlich merken, wer wann die daten zum rendern genommen hatte, um ggf. veraltete ergebnisse ablehnen zu können. Das alles setzt natürlich voraus, dass niemand mutwillig unfug macht. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Linie aus dem Nichts?
Hallo, Ich habe in dem Stadtpark Hanny-Franke-Anlage in Eschborn im Output des OSMArenderers in der stärksten Zoomstufe eine dunkelgrüne Linie, die ich nicht zuordnen kann. http://www.openstreetmap.org/?lat=50.14095lon=8.57844zoom=17layers=0BFT Es handelt sich um eine Außenlinie für die Grünfläche, die jedoch in der Mitte liegt. Da ich sie per Editor (Potlatch) nicht sehe und sie jetzt schon seit rund 4-5 Tagen dort unverändert im Output liegt, also auch nicht durch Neurendering verschwunden ist, frage ich jetzt hier. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Am Montag 12 Mai 2008 02:19:44 schrieb Frederik Ramm: Hallo, Leider schleicht es immer noch ordentlich. Schalte doch einfach die Polygonfuellerei ab, wenn Du einen langsameren Rechner hast - so wichtig ist das doch nicht. Ich selber arbeite meistens sogar mit dem Wireframe-Modus, weil mir alles andere zu bunt ist ;-) Dito. Meistens schalte ich nur dann um, wenn ich etwas die Uebersicht verloren habe oder etwas Bestimmtes suche. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] OSM Präsentationen in Hamburg
2 Präsentationen in Hamburg: Am 6. Juni 2008 ist OSM zum Communities Meeting Hamburg 2008 eigeladen. Location: Lehmann's http://linuxwiki.de/Communities/MeetingHamburg2008 Ich will die Vorstellung nicht alleine vorbereiten und suche gerade für den softwarespezifischen Part Unterstützung. Am 5. Juli 2008 nimmt OSM zum 2. Mal am Umsonstfest in Hamburg mit einem Infostand teil. Der Ansturm im vergangenen Jahr war sehr groß, so dass eine zweite Person von uns willkommen wäre. http://www.neue-arbeit-hamburg.de/pmwiki.php/Main/Umsonstfest Gruß, Stephan. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Linie aus dem Nichts?
Ich habe in dem Stadtpark Hanny-Franke-Anlage in Eschborn im Output des OSMArenderers in der stärksten Zoomstufe eine dunkelgrüne Linie, die ich nicht zuordnen kann. [...] Es handelt sich um eine Außenlinie für die Grünfläche, die jedoch in der Mitte liegt. Da war ein Fußweg als leisure=park getaggt, somit wurde dieser Weg auch als Park-Area gerendert (mit grüner Kontur). Ich habe den Tag entfernt. Gruß, Daniel___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Linie aus dem Nichts?
Ich habe in dem Stadtpark Hanny-Franke-Anlage in Eschborn im Output des OSMArenderers in der stärksten Zoomstufe eine dunkelgrüne Linie, die ich nicht zuordnen kann. [...] Es handelt sich um eine Außenlinie für die Grünfläche, die jedoch in der Mitte liegt. Da war ein Fußweg als leisure=park getaggt, somit wurde dieser Weg auch als Park-Area gerendert (mit grüner Kontur). Ich habe den Tag entfernt. Das war noch bei zwei anderen Fußwegen so; da hab ichs jetzt auch entfernt. Gruß, Daniel Grüße, Marc -- 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro. Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] rendert uralte Daten?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Eichwalder schrieb: Sven Geggus schrieb: Henry Loenwind [EMAIL PROTECTED] wrote: Das passiert aber leider sehr einfach. z.B. Rechner runterfahren, 2 Wochen in Urlaub gehen, tah starten. Schwupp, alte Daten im Upload... *argh* Dann sollte man die scripten so anpassen, dass sie nur Dinge hochladen, die zeitnah gerendert wurden. Na (fränggisch), das wäre auch nicht viel besser. Schaut euch doch mal an, das der Build-Service-Scheduler von openSUSE das macht (vor einiger zeit hatte ich schon einmal darauf hingewiesen). Stichworte: Hochrechnen, wie lang ein tile normalerweise unterwegs ist. Wird diese zeit überschritten, kann das tile neu vergeben werden. Der scheduler muss sich natürlich merken, wer wann die daten zum rendern genommen hatte, um ggf. veraltete ergebnisse ablehnen zu können. Ich verstehe nicht ganz, was das damit zu tun hat, dass ein ZIP auf einem [EMAIL PROTECTED] rechner 2 Wochen lang rumliegt, bevor es hochgeladen wird? - -- 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 iD8DBQFIKCc2FUbODdpRVDwRAiXoAJ97BH9m7m45yL7bjMuojAk9cuTQEgCcDb+z xD+tzuXLMVcx7tzR50O6EvI= =Dpg+ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Merkaartor erweitern?
Am Montag, den 12.05.2008, 12:25 +0200 schrieb Daniel van Gerpen: Ich habe das Verhalten unter Linux reproduzieren koennen Ist es bei Dir auch abgeschmiert? Wie hat sich das geäußert? Is ganz wichtig für mich, also danke schonmal. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM und Background Farbe - ev. Bug
On Montag, 12. Mai 2008, Stefan Hirschmann wrote: Wollte heute wieder mal was mit JOSM taggen, aber JOSM ignoriert meine Hintergrundfarbe (heute erst josm-latest.jar) herunter geladen. Sieht man den Track nach dem Laden der OSM-Daten überhaupt noch? Wenn nicht, ist es wohl dieser Bug: http://josm.openstreetmap.de/ticket/736 mfg Daniel -- http://www.danielnaber.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Yahoo Bilder in Josm anzeigen
Wenn ich Bilder vom Yahoo Server herunterlade, kann ich immer nur die Bilder sehen, oder die OSM Daten. Wie kriege ich das transparent? Außerdem muß ich meinen Firefox immer erst wieder schließen damit ich ein zweites oder drittes Tile runterladen kann. Wie ändere ich das? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Yahoo Bilder in Josm anzeigen
On Montag, 12. Mai 2008, Sven Sommerkamp wrote: Wenn ich Bilder vom Yahoo Server herunterlade, kann ich immer nur die Bilder sehen, oder die OSM Daten. Wie kriege ich das transparent? Warten bis dieser Bug behoben ist oder den Vorschlag dort selber lokal in den Source einbauen: http://josm.openstreetmap.de/ticket/736 mfg Daniel -- http://www.danielnaber.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM und Background Farbe - ev. Bug
Daniel Naber [EMAIL PROTECTED] wrote: Sieht man den Track nach dem Laden der OSM-Daten überhaupt noch? Wenn nicht, ist es wohl dieser Bug: http://josm.openstreetmap.de/ticket/736 Jupp. Das selbe hier. Wo bekomme ich denn jetzt auf die schnelle eine funktionierende josm Version her. Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM und Background Farbe - ev. Bug
Hi, Sieht man den Track nach dem Laden der OSM-Daten überhaupt noch? Wenn nicht, ist es wohl dieser Bug: http://josm.openstreetmap.de/ticket/736 Jupp. Das selbe hier. Wo bekomme ich denn jetzt auf die schnelle eine funktionierende josm Version her. Alte Versionen sind grundsaetzlich immer auf josm.openstreetmap.de/download/ zu finden. Daniel - habe ich da einen falschen Patch eingespielt, oder hattest Du den repariert, nachdem ich ihn eingespielt hatte? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM - langsam bei ausgefüllten Polygo nen?
Andreas Jacob wrote: Am Montag, 12. Mai 2008 05:42:13 schrieb Henry Loenwind: Wie gesagt, draw.rawgps.trianglelines ist bei mir mehr als 10 mal schneller als einfache Linien - und ich verstehe es nicht... Mal in's Blaue hinein vermutet. Die Engines von Grafikkarten bzw. die ansteuernden Treiber sind doch alle auf das Arbeiten mit Dreiecken getrimmt. Na, das ist es nicht. Langsam: g.drawLine(old.x, old.y, screen.x, screen.y); Schnell: g.drawLine(old.x+2, old.y+2, screen.x, screen.y); Also in dem Moment, in dem die Linie dort weitergeht, wo die letzte aufgehört hat, ist es schnarchlangsam. Der Name des Settings bezieht sich nur auf die Form, die dabei rauskommt, da ich dann eben 2 versetzte Linien zeichne (um genau zu sein, diese gehen von den Endpunkten der Pfeil-Linien zum nächsten Punkt). cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] rendert uralte Daten?!
Dirk-Lüder Kreie wrote: Karl Eichwalder schrieb: Stichworte: Hochrechnen, wie lang ein tile normalerweise unterwegs ist. Wird diese zeit überschritten, kann das tile neu vergeben Macht er schon, wenn auch nicht dynamisch. Ich verstehe nicht ganz, was das damit zu tun hat, dass ein ZIP auf einem [EMAIL PROTECTED] rechner 2 Wochen lang rumliegt, bevor es hochgeladen wird? Relativ einfaches Verständnisproblem: Während der Server über Renderaufträge genau buchführt, die neu vergibt, wenn ein Client nicht liefert oder den Auftrag zurückgibt, weil es nicht klappt, ist das Hochladen unabhängig von diesen Aufträgen. d.h. Der Server nimmt alle Uploads an und verarbeitet sie. Wenn damit ein Auftrag befriedigt wird, gut. Wenn nicht, auch gut. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
