Can someone point me to discussions regarding OSB and MapDust? I'm not sure if there have been any, but I couldn't easily find any. OSB is mentioned on the MapDust wiki page, but not the other way.
MapDust seems fairly well developed, though I understand the MapDust DB is privately operated, so I know it not something OSB could use. But what about learning from what they've done, or perhaps working together to use a common API? That way there could be multiple bug services, some privately operated (like Skobbler/MapDust) and others like OSB, but consumers could all use the same plugins, web interfaces, etc. -Josh On Sun, May 1, 2011 at 3:41 PM, Steve Coast <st...@asklater.com> wrote: > WORKSFORME > > Is it still correct to call is OSB though? It feels like a rewrite, > integrated in to the rails_port. When you say OSB I think of .... OSB. > > Steve > > On 5/1/2011 12:37 PM, Kai Krueger wrote: >> >> Should we not move the discussion about the details of the OpenStreetBugs >> implementation from the strategic mailing list over to the dev list? (which >> I have CCed) >> >> It seems there is general consensus about that if technically done >> correctly, an instance of OpenStreetBugs integrated into the main page would >> be welcomed and useful, so the strategic aspect is done and we are now well >> into the implementation phase. >> >> Kai >> >> On 29/04/2011 13:55, Steve Coast wrote: >>> >>> So I played with it, it looks pretty good. My changes would be >>> relatively minor, plus some questions. >>> >>> * Only let me enter bugs when zoomed in a fair way >>> * Don't show me all the bugs just by default on the map. >>> * I really don't believe in having to click the map again to enter a >>> bug. My mum would be confused. Just use the center point of the map. So >>> the model is, click to enter bug, popup, it says "be as descriptive as >>> possible", done. The extra click makes a lot of sense for you and me, >>> but not someone new. I know there are a ton of "but, but, but" arguments >>> against this, but really, simple is _so_ much better. >>> >>> Now questions >>> >>> * I'm assuming the API looks sane? >>> * I'm assuming the data is all going in to whatever rails db is talking >>> to, not some magical special other db? >>> * I'm assuming there has been some cross-browser testing? >>> * I'm assuming there is a proper db migration >>> >>> I'm happy to take a peek at the code too and make some adjustments, >>> where is it? >>> >>> Steve >>> >>> >>> >>> On 4/29/2011 10:39 AM, Kai Krueger wrote: >>>> >>>> On 04/29/2011 02:56 AM, Eugene Usvitsky wrote: >>>>> >>>>> * "Report an error" link to OpenStreetBugs >>>> >>>> I'd like to mention that there is a (more or less) fully functional >>>> implementation of the "Report an error" functionality at >>>> http://openstreetbugs.dev.openstreetmap.org/ >>>> >>>> It is heavily modeled after the ideas of the original OSB (and uses >>>> large parts of the client javascript written by Candid Dauth), but is >>>> fully integrated into the rails_port. Apart from having the bugs >>>> stored in the main OSM database, this also allows to hook into OSM's >>>> user management to make it easier to keep track of your own bugs and >>>> bug comments. This might make it easier to communicate between bug >>>> reporter and mapper. >>>> >>>> The Api was also slightly adopted from the original OSB API to be more >>>> in line with the other rails APIs. It is mostly a rename, though, so >>>> it shouldn't be difficult to adapt existing clients to the new API. >>>> >>>> A year ago, when I did the bulk of the coding, I talked to Mitja >>>> Kleider (the maintainer of the current OSB instance) about possible >>>> transition strategies from the external OSB instance to the integrated >>>> one once things are ready. He said it would probably be possible to >>>> use the existing URLs as a proxy to not cause any disruption for >>>> existing clients in the transition period and thus gracefully moving >>>> over without any losses. >>>> >>>> Tom has just agreed to have a look at the code and review it in the >>>> next couple of weeks, so depending on what his review sais and how >>>> much change and clean up is necessary, we might be able to see some >>>> progress on this fairly soon. >>>> >>>> If people have comments and suggestions on what can be improved, I'd >>>> be grateful for any tips. However, my priority is on getting something >>>> workable and usable actually deployed before adding too many new >>>> features. >>>> >>>> Kai >>>> >>>> _______________________________________________ >>>> Strategic mailing list >>>> strate...@openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/strategic >>>> >>> >>> _______________________________________________ >>> Strategic mailing list >>> strate...@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/strategic >> >> > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev > _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev