[OSM-talk] [tagging] Feature Proposal - RFC - Residential home
The object of this proposal is to add a new value "residential_home" to the "amenity"-tag amenity=residential_home. There are places where people, who for different reasons can't stay alone or in their families, live. The idea is to create a tag/amenity that covers these places in general and which can be specified in more details by adding additional tags e.g. according to the people who live there. http://wiki.openstreetmap.org/wiki/Proposed_features/Residential_home It's my first proposal so I hope I did everything "the correct way" so far. Glad for any hints... Birgit ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Residential home
--- On Fri, 17/7/09, Birgit Huesken wrote: > There are places where people, who for different reasons > can't stay > alone or in their families, live. The idea is to create a What you are describing is normally known (at least here) as "shelters". For homeless people and domestic violence victims etc. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Walking Papers plugin for JOSM
Awesome. I suited up before trying but re-entry was a breeze ;-) Cheers Andy >-Original Message- >From: talk-boun...@openstreetmap.org [mailto:talk- >boun...@openstreetmap.org] On Behalf Of Frederik Ramm >Sent: 17 July 2009 1:09 AM >To: Talk Openstreetmap >Subject: [OSM-talk] Walking Papers plugin for JOSM > >Hi, > >there's now a Walking Papers plugin for JOSM. Download it via the >usual plugin download mechanism, click on the new "Walking Papers" menu, >and enter the ID for the scanned map you have uploaded to >walking-papers.org, and you should be ready to go. > >It is still in its early stages and it might reduce drawing performance >a bit. I'm interested to hear usability reports. > >Bye >Frederik > >-- >Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SoC 2009 - static maps API - prototype version
Maybe I'm wrong, but it looks to me like the attribution is not correct, you must also mention CC-BY-SA! Jonas Am 17.07.2009 um 01:57 schrieb Paweł Niechoda : Thanks for respond!! W dniu 16 lipca 2009 17:36 użytkownik Jochen Topf > napisał: Hi! On Thu, Jul 16, 2009 at 04:18:35PM +0200, Paweł Niechoda wrote: > My name is Paweł Niechoda and I am a student who is involved in Go ogle SoC > 2009. > I am working on project: OSM static maps API. > I know that asking end-users for feedback is always the best way to improve > application. So I am doing it. > Here you can find the description of the prototype version of the API: > http://dev.openstreetmap.org/~pafciu17/ > and examples how API works. > Please feel to send me any comments or sugestions for new features. > By doing this you would help me a lot with my work. Looks very promising! Two small comments: * I suggest to allow giving center by &lat=...&lon=... instead of (or in addition to ¢er=...) Thats the format used most widely and it has the advantage on not relying on the order of the longitude/ latitude coordinates. Yeah, you are right, it is nice just to specify center point by giving &lat and &lon params. So I added that possiblity, now there are two ways, you can use either &lat and &lon or just ¢er. * type for the ti...@home-map should be "osmarender" (not the "a"). Done I am a bit concerned about the format of the points and paths. Its very hard to see anything if all seperator characters are commas. Maybe have a look at the Well-known text format (http://en.wikipedia.org/wiki/Well-known_text ) as another option. Might be a bit easier to read, on the other hand having spaces in URLs is also bad. Your choice. :-) I have had a look at Well-known text format, for sure it would be nice to support it. As you mentioned it looks nice. I will remember about it. Now I think there are some others more important issues to work on. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 thank you again for comments:) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Residential home
2009/7/17 John Smith : > > --- On Fri, 17/7/09, Birgit Huesken wrote: > >> There are places where people, who for different reasons >> can't stay >> alone or in their families, live. The idea is to create a > > What you are describing is normally known (at least here) as "shelters". For > homeless people and domestic violence victims etc. > > Yes and Retirement Homes/Old People Homes, Homes for the Disabled. etc etc. Maybe we need a tag for Day Care, and Drop in Centre as well. A Shelter is a type of Residential Home, not all Residential Home will be Shelters. Peter Childs ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Residential home
>> There are places where people, who for different reasons >> can't stay >> alone or in their families, live. The idea is to create a > > What you are describing is normally known (at least here) as "shelters". For > homeless people and domestic violence victims etc. > If I understood you correctly, shelters are something like "emergency places" or homes where people stay for a comparably short time. What I mean are places where people really _live_ instead of staying alone or with their families, not for emergency reasons but following a decision well thought over. Don't know if this sounds a bit pathetic but I don't know how to describe it in a better way at the moment. Birgit -- Birgit Hüsken IT Service Management ITSM Hochschule Niederrhein KIS - Kommunikations-/Informationssysteme, Services Niederrhein University of Applied Sciences Communication-/Informationsystems, Services Reinarzstr. 49 D – 47805 Krefeld Telefon: +49 2151 822 3225 birgit.hues...@hs-niederrhein.de http://www.hs-niederrhein.de ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Residential home
--- On Fri, 17/7/09, Birgit Huesken wrote: > If I understood you correctly, shelters are something like > "emergency > places" or homes where people stay for a comparably short > time. > What I mean are places where people really _live_ instead > of staying > alone or with their families, not for emergency reasons but > following > a decision well thought over. Don't know if this sounds a > bit pathetic > but I don't know how to describe it in a better way at the > moment. What Peter put "Yes and Retirement Homes/Old People Homes, Homes for the Disabled. etc etc." ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Residential home
Birgit Huesken wrote: >>> There are places where people, who for different reasons >>> can't stay >>> alone or in their families, live. The idea is to create a >> What you are describing is normally known (at least here) as "shelters". For >> homeless people and domestic violence victims etc. >> > > If I understood you correctly, shelters are something like "emergency > places" or homes where people stay for a comparably short time. > What I mean are places where people really _live_ instead of staying > alone or with their families, not for emergency reasons but following > a decision well thought over. Don't know if this sounds a bit pathetic > but I don't know how to describe it in a better way at the moment. Residential Home in the UK is definitely a term to describe a place where usually elderly people, but vulnerable people in general, live communally, usually involving professional care and sometimes advanced medical care (though this is often called a Nursing Home; the distinction is not a hard one). So I think your tag is an appropriate description. Emergency shelters are something else. (And in many cases will not be recognisable from the street as they often need to be discreet - e.g. refuges) David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - Destination signs (realation)
Extending the voting period for the destination signs relation due to few votes. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Destination_Signs /Konrad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Tue, Jul 14, 2009 at 03:15:44PM +0200, Mitja Kleider wrote: > I would like to see a bugtracker like this on the main page. My first > attempts > to get in touch failed and I lost interest. Candid Dauth is currently working > on a client that can easily be added as a layer in OpenLayers. How far is that code? I am interested to include an OSB bug layer into the maxspeed map. Flo -- Florian Lohoff f...@rfc822.org 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/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Any reason why we don't just put the bugs in osm. They could be nodes, ways or polygons and just have a suitable bug=description key value pair plus any other tags need (date opened/closed etc). I accept that the editors would need to handle the data a little differently and their might be a need to track closed (visible=false or perhaps a new visible=closed). Plus the API would need to able to deliver just the bug data for the API rather than the whole dataset for the bbox. It seems daft to me to go reinventing everything when we have all the tolls already. Cheers Andy >-Original Message- >From: talk-boun...@openstreetmap.org [mailto:talk- >boun...@openstreetmap.org] On Behalf Of SteveC >Sent: 02 July 2009 1:16 PM >To: Frederik Ramm >Cc: Talk Openstreetmap >Subject: Re: [OSM-talk] The future of bugs in OSM > > >On 1 Jul 2009, at 19:58, Frederik Ramm wrote: > >> Hi, >> >> SteveC wrote: >>> But, and this is key, it also has a RESTful API for mass uploading >>> of bugs. >>> We need to do two things - unify the various bug systems and >>> expose more of the bugs. >> >> I believe that the types of bugs one can look for are quite >> different. You'd have to build a very good system if it is to be >> able to capture all kinds of bugs - don't think that simply having >> something like lat/lon/text is enough, because some bugs might be >> relevant for a whole area, or you might have a "two nearby streets >> share the same name" bug which points to two ways rather than one >> location, etc etc > >How about we borrow tags from OSM? Bugs have lat,lng,text and keyvals? >What you think? > >They main thing I want to say though - is lets just build something >simple and iterate. Absolutle minimum feature set is a RESTful API >plus a OSB-like interface. > >> Not saying it can't be done but if you want to replace the various >> bug systems then you need to be able to do what they can do or it is >> a step backwards. >> >> I'm also wary of the centralistic "let's set up a database and have >> everyone upload their data to us" approach. Maybe keeping true to >> your "clearinghouse" idea the central service should *only* know >> that there is some other service that has found a bug in a certain >> location, and when the user wants to know more, the other service is >> interrogated through an API. The other service might, for example, >> guide the user through an automatic fixing process for certain types >> of bugs, or offer things like "find similar bugs in the vicinity" or >> so. Plus, every coder could contribute to something like that in the >> language(s) he prefers, and without having to ask for his >> functionality to be included in some central service. > >Yeah so if you want it to just also aggregate things like keepright or >OSB, it's easy to write things to do that, so long as they have APIs. > >Best > >Steve > > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Bug should be separate from the real data. The bugs should stored in separate tables, or a separate server using the same/similar stack as the real data. Shaun On 17 Jul 2009, at 14:05, Andy Robinson (blackadder-lists) wrote: Any reason why we don't just put the bugs in osm. They could be nodes, ways or polygons and just have a suitable bug=description key value pair plus any other tags need (date opened/closed etc). I accept that the editors would need to handle the data a little differently and their might be a need to track closed (visible=false or perhaps a new visible=closed). Plus the API would need to able to deliver just the bug data for the API rather than the whole dataset for the bbox. It seems daft to me to go reinventing everything when we have all the tolls already. Cheers Andy -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] On Behalf Of SteveC Sent: 02 July 2009 1:16 PM To: Frederik Ramm Cc: Talk Openstreetmap Subject: Re: [OSM-talk] The future of bugs in OSM On 1 Jul 2009, at 19:58, Frederik Ramm wrote: Hi, SteveC wrote: But, and this is key, it also has a RESTful API for mass uploading of bugs. We need to do two things - unify the various bug systems and expose more of the bugs. I believe that the types of bugs one can look for are quite different. You'd have to build a very good system if it is to be able to capture all kinds of bugs - don't think that simply having something like lat/lon/text is enough, because some bugs might be relevant for a whole area, or you might have a "two nearby streets share the same name" bug which points to two ways rather than one location, etc etc How about we borrow tags from OSM? Bugs have lat,lng,text and keyvals? What you think? They main thing I want to say though - is lets just build something simple and iterate. Absolutle minimum feature set is a RESTful API plus a OSB-like interface. Not saying it can't be done but if you want to replace the various bug systems then you need to be able to do what they can do or it is a step backwards. I'm also wary of the centralistic "let's set up a database and have everyone upload their data to us" approach. Maybe keeping true to your "clearinghouse" idea the central service should *only* know that there is some other service that has found a bug in a certain location, and when the user wants to know more, the other service is interrogated through an API. The other service might, for example, guide the user through an automatic fixing process for certain types of bugs, or offer things like "find similar bugs in the vicinity" or so. Plus, every coder could contribute to something like that in the language(s) he prefers, and without having to ask for his functionality to be included in some central service. Yeah so if you want it to just also aggregate things like keepright or OSB, it's easy to write things to do that, so long as they have APIs. Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Am Freitag, 17. Juli 2009 schrieb Florian Lohoff: > On Tue, Jul 14, 2009 at 03:15:44PM +0200, Mitja Kleider wrote: > > I would like to see a bugtracker like this on the main page. My first > > attempts to get in touch failed and I lost interest. Candid Dauth is > > currently working on a client that can easily be added as a layer in > > OpenLayers. > > How far is that code? I am interested to include an OSB bug layer into the > maxspeed map. It is not finished yet and is delayed until October or later. You may check out his older implementation in the meantime: http://osm.cdauth.de/ by http://www.openstreetmap.org/user/Candid%20Dauth Regards, Mitja ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] wrote: >Sent: 17 July 2009 2:30 PM >To: Andy Robinson (blackadder-lists) >Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap' >Subject: Re: [OSM-talk] The future of bugs in OSM > >Bug should be separate from the real data. The bugs should stored in >separate tables, or a separate server using the same/similar stack as >the real data. > >Shaun > Can you elude as to why you take this point of view? Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Jul 17, 2009, at 8:00 AM, Andy Robinson (blackadder-lists) wrote: > Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] wrote: >> Sent: 17 July 2009 2:30 PM >> To: Andy Robinson (blackadder-lists) >> Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap' >> Subject: Re: [OSM-talk] The future of bugs in OSM >> >> Bug should be separate from the real data. The bugs should stored in >> separate tables, or a separate server using the same/similar stack as >> the real data. >> >> Shaun >> > > Can you elude as to why you take this point of view? I'm curious also. We already have meta-metadata (FIXME= or note=). Why not metameta-data? -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On 17 Jul 2009, at 16:00, Andy Robinson (blackadder-lists) wrote: Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] wrote: Sent: 17 July 2009 2:30 PM To: Andy Robinson (blackadder-lists) Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap' Subject: Re: [OSM-talk] The future of bugs in OSM Bug should be separate from the real data. The bugs should stored in separate tables, or a separate server using the same/similar stack as the real data. Shaun Can you elude as to why you take this point of view? Data users shouldn't have to deal with bug tracking data in the planet. The planet export script should not be doing any tag inspection to selectively dump data to the planet. Editing will be harder and more confusing if you have bug data around with no easy way to switch it off. I see the bug tracking as an added extra, rather than a core part of OSM. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] wrote: >Sent: 17 July 2009 4:20 PM >To: Andy Robinson (blackadder-lists) >Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap' >Subject: Re: [OSM-talk] The future of bugs in OSM > > >On 17 Jul 2009, at 16:00, Andy Robinson (blackadder-lists) wrote: > >> Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] wrote: >>> Sent: 17 July 2009 2:30 PM >>> To: Andy Robinson (blackadder-lists) >>> Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap' >>> Subject: Re: [OSM-talk] The future of bugs in OSM >>> >>> Bug should be separate from the real data. The bugs should stored in >>> separate tables, or a separate server using the same/similar stack as >>> the real data. >>> >>> Shaun >>> >> >> Can you elude as to why you take this point of view? > >Data users shouldn't have to deal with bug tracking data in the >planet. The planet export script should not be doing any tag >inspection to selectively dump data to the planet. Agreed, but I still think since bug tracking is part of the core of what we do it should ultimately be part of the database somewhere. I don't care how its achieved so long as its available via the same api call setup. If it uses the same syntax for data as the rest of the database for objects then we don't have to lean something new just for bugs. > >Editing will be harder and more confusing if you have bug data around >with no easy way to switch it off. I see the bug tracking as an added >extra, rather than a core part of OSM. > It will only be confusing if it's displayed to the use with the rest of the data and I wouldn't want that either. The editing software just needs to display bugs on a separate layer or whatever. Or perhaps even ignore them if it's not an ap that needs to know about bugs. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Fri, Jul 17, 2009 at 4:35 PM, Andy Robinson (blackadder-lists) wrote: > It will only be confusing if it's displayed to the use with the rest of the > data and I wouldn't want that either. The editing software just needs to > display bugs on a separate layer or whatever. Or perhaps even ignore them if > it's not an ap that needs to know about bugs. That's practically an argument for keeping them separate in the first place. For the same reason that we have trac for software bugs (we don't get people to add new bug reports in comments into the source files) we shouldn't put bugs directly into the geodata. Next thing we'd be doing something horrid to the tags so that I can reply to a bug saying "bug:151234:gravitystorm:20090715=I've been there, but it looks fine to me" and then building tools to parse all that stuff. The geodata tables are for geodata. We're already trying to prise the non-geodata tags out of the geodata (e.g. putting created_by on changesets). Lets not take five steps backwards by putting bugs in as nodes/ways/relations. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Fri, Jul 17, 2009 at 9:05 PM, Andy Robinson (blackadder-lists) < ajrli...@googlemail.com> wrote: > Any reason why we don't just put the bugs in osm. They could be nodes, ways > or polygons and just have a suitable bug=description key value pair plus > any > other tags need (date opened/closed etc). I accept that the editors would > need to handle the data a little differently and their might be a need to > track closed (visible=false or perhaps a new visible=closed). Plus the API > would need to able to deliver just the bug data for the API rather than the > whole dataset for the bbox. > > It seems daft to me to go reinventing everything when we have all the tolls > already. > -1 I see bugs data as similar to the GPX traces. It should be on a separate layer with separate database tables, etc. I agree that we don't need to reinvent everything (we can reuse components of the OSM stack) but as Shaun said, bug data should be separate from the real data. Existing tools should not be retrofitted to ignore such bug info. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
2009/7/17 Andy Allan > > That's practically an argument for keeping them separate in the first > place. > > For the same reason that we have trac for software bugs (we don't get > people to add new bug reports in comments into the source files) we > shouldn't put bugs directly into the geodata. Next thing we'd be doing > something horrid to the tags so that I can reply to a bug saying > "bug:151234:gravitystorm:20090715=I've been there, but it looks fine > to me" and then building tools to parse all that stuff. > > The geodata tables are for geodata. We're already trying to prise the > non-geodata tags out of the geodata (e.g. putting created_by on > changesets). Lets not take five steps backwards by putting bugs in as > nodes/ways/relations. > > I agree that we should not start putting the bugs into the geodata. It will make the database even heavier for no real advantages. Keeping a separate database is a much saner option and much manageable. It also allows the use of workflow which is always useful when managing a bug. If you put this inside the geodata, you lose that kind of flexibility. Emilie Laffray ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Eugene Alvin Villar [mailto:sea...@gmail.com] wrote: >Sent: 17 July 2009 4:56 PM >To: Andy Robinson (blackadder-lists) >Cc: SteveC; Frederik Ramm; Talk Openstreetmap >Subject: Re: [OSM-talk] The future of bugs in OSM > > > >On Fri, Jul 17, 2009 at 9:05 PM, Andy Robinson (blackadder-lists) > wrote: > > > Any reason why we don't just put the bugs in osm. They could be >nodes, ways > or polygons and just have a suitable bug=description key value pair >plus any > other tags need (date opened/closed etc). I accept that the editors >would > need to handle the data a little differently and their might be a >need to > track closed (visible=false or perhaps a new visible=closed). Plus >the API > would need to able to deliver just the bug data for the API rather >than the > whole dataset for the bbox. > > It seems daft to me to go reinventing everything when we have all the >tolls > already. > > > >-1 > >I see bugs data as similar to the GPX traces. It should be on a separate >layer with separate database tables, etc. I agree that we don't need to >reinvent everything (we can reuse components of the OSM stack) but as Shaun >said, bug data should be separate from the real data. Existing tools should >not be retrofitted to ignore such bug info. > Very happy to have these recent responses to my question. I was really only stirring the honey pot a little. What appears to fall out for me is that: 1. A separate database is desirable. 2. We could reuse a lot of the stack, including the tag structure. I suspect however that those who have experience of software bug track might have a different perspective. Am I correct? Which is the simplest approach, since it's the simplest working method that's likely to be what will sit best with the rest of the project. So what else is important? Are points sufficient for marking bugs? I'd say not. I'd like to be able to set a polygon as well and possibly even a line. No different from a node/way/poly in geographical terms. How can I link a bug to an object in the main db? I'll want to do that too, but not always. Sometimes I'll want to effectively make a feature request (a bug for an unmapped object/area) Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] More Best of OSM
Jochen Topf remote.org> writes: >Thanks for the many ideas on the "Best of OSM" web site (bestofosm.org). I was doing a lot of zooming to get to each feature and I wondered why there wasn't a link in each bubble to go there directly. It's not obvious you have to click on the small picture! So I suggest adding a 'go there' link to each bubble, even though it is redundant. Also maybe you could add a 'next cool thing' link to let you skip through each bubble in a circle, like skipping to the next episode in a webcomic. -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Fri, Jul 17, 2009 at 4:24 PM, Andy Robinson (blackadder-lists) wrote: > 1. A separate database is desirable. > [...] > Are points sufficient for marking bugs? I'd say not. I'd like to be able to > set a polygon as well and possibly even a line. No different from a > node/way/poly in geographical terms. > > How can I link a bug to an object in the main db? I'll want to do that too, > but not always. Sometimes I'll want to effectively make a feature request (a > bug for an unmapped object/area) I'd prefer to be able to file bugs that have referential integrity with the main database, e.g. to file a bug with a given relation or other object. But maintaining that sounds more like a separate table rather than an altogether separate database. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
