Re: [josm-dev] JOSM language plugins and stable version?
On Tue, Nov 4, 2008 at 8:28 AM, Dirk Stöcker [EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, Florian Schmitt wrote: it seems that the lang-* plugins aren't available any more. This means that new users who want to use the last stable version 1010 aren't able to change the language of JOSM. I think as long as a stable version is recommended, the localisation plugins should be available, even if they're not necessary for the latest build. Would it be possible to provide the lang-Plugins again? I updated the stable to 1065. but this stable is also missing translations until build script is adjusted so that the jar includes translations. Stefan ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] arbitrariness of relations [was: HEADS UP osmosis pgsql schema users]
On Tue, November 4, 2008 16:58, Roland Olbricht wrote: In particular, I'm wondering how I should encode the coastline-boundary-12-nm-data. As the upload of a lot of ways over the api will take a lot of time, I would like to avoid doing it twice. Currently, the multipolygon-relation, although rarely used, looks best to me but I'm still unsure. The Boundaries relation ( http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries ) seems to be the ideal solution. At least, you can differentiate the borders from lakes with islands by looking at the type of the relation :-) So where do I find the consensus whether this is a good idea or not? I'm grateful for any comments. Do it the OSM way, just use the relation :-) Regards, Hakan -- The key to immortality is first living a life worth remembering... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] arbitrariness of relations [was: HEADS UP osmosis pgsql schema users]
Dear all, Hugh Barnes wrote: I had a very different different idea of what relations were before I looked at them properly. I was disappointed to see that they just appear to be named groupings. … They are what you make them to be. I think, relations are exactly *not* that way. Of course, there is no formal prohibition or technical constraint. But the purpose of any data including relations is to be understood by another algorithm. So a type of relation becomes useful if a lot of mappers use it with the same syntax and semantics. Thus, maintaining relations coherent by e.g. http://wiki.openstreetmap.org/index.php/Relations sounds like a good idea, and maybe its also a good idea to donate some life the discussion process there. Thus, also people not reading this list can participate. Note that the relations in the database currently only rarely obey the consensus on the wiki page, but this might change as with the proposed features page. Cheers, Roland ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
Erik Johansson wrote: This is a really naive and contraproductive argument, nothing is black and white. You have to define what it is you are mapping, and you don't do that in the database. Yeah, but therein lies the problem. The people doing the defining are, in many cases, not the ones who are doing the mapping. There are plenty of people voting on things just because they like voting. If people refrained from discussing and voting unless they had _personally_ come up against the problem that the proposal was aiming to solve, I think the process would have a lot more respect. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] HEADS UP osmosis pgsql schema users Was: psql osmosis simple shema / smallint out of range
Hi, Andy Allan wrote: Nice. Much of this I suspect is because people really, really don't understand the spatial bit of spatial databases. Many also don't understand the databases bit of spatial databases ;-) To be fair, we don't exactly exhibit a lot of database power through our API (for obvious reasons). It is relatively easy to request all object relocations in area A performed by any user whose home base is not in A, within the last 2 months, from a database, but impossible for Joe Mapper to request that from our database. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] arbitrariness of relations [was: HEADS UP osmosis pgsql schema users]
On Tue, Nov 4, 2008 at 3:58 PM, Roland Olbricht [EMAIL PROTECTED] wrote: Thus, the following things happen - people convert data from one representation to another, while other people just convert it the other way back - looks a little bit like an edit war - a lot of code in any piece of software processing this data is needed to cope with the different representations and solve arising conflicts did you mean: - people edit the data in a similar manner to a wiki. - code has to be written in a flexible and robust fashion to work with global data. i understand that both points have problems as well as advantages, but an ecosystem of tags is better than a monoculture (a.k.a fixed ontology) at dealing with unexpected features. eventually, one system of tagging a particular feature will become dominant because it has been successfully used in many places and by many editors. this is evolution. On the other hand, if you find a consensus on the representation of the data, you can put effort in - encoding the data in this particular representation - implementing this particular representation properly in all pieces of software ah, you mean intelligent design? in my experience, this leads to systems that look good on paper. however, at some point they are unable to properly represent a feature, or become overly complex. cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Reminder - upcoming API development events
Hi All, Seeing Ivan's new icon for dev events on the wiki prompted me to send out a quick reminder of the two upcoming development events over the next few days: Wednesday evening - APIzza 0.6. Come along and get familiar with the code that powers the OSM API - and have some pizzas too! Perfect for those wanting to get started with OSM API coding. http://wiki.openstreetmap.org/index.php/APIzza_0.6 This weekend - API Hack weekend. It's (hopefully) finishing off time for API 0.6, but there's still a lot of work to be done. http://wiki.openstreetmap.org/index.php/2nd_International_OSM_Hack_Weekend Both are being held in Central London - full details on the wiki pages. Give me a shout if you have any questions! Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] HEADS UP osmosis pgsql schema users Was: psql osmosis simple shema / smallint out of range
On Mon, Nov 3, 2008 at 6:47 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Increasingly, and I believe this is born from unreflected Wikipedia customs being applied here, people make collections or categories using relations, for example cycle network North-Rine-Westphalia containing every cycle route in that part of Germany, or another relation containing every German Autobahn, or one containing all McDonald's restaurants. Nice. Much of this I suspect is because people really, really don't understand the spatial bit of spatial databases. We still have strong proponents of is_in style tagging on every object in a town, when the more sane way to do that is to delineate the town itself and use some spatial maths. Ditto with spatial-collections like All X in area Y, which is utterly redundant. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Resource bundle not found exception
Stefan Baebler wrote: Frederik confirmed a few days ago that automatic building is not done with ant. That probably needs to be changed, or scripts adjusted accordingly. Just to close this thread - the automated build of JOSM is not done with ant but relevant build scripts have been updated and all releases of JOSM contain translations. Regards, Marcin ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] HEADS UP osmosis pgsql schema users Was: psql osmosis simple shema / smallint out of range
On Tue, November 4, 2008 12:10, Andy Allan wrote: On Mon, Nov 3, 2008 at 6:47 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Increasingly, and I believe this is born from unreflected Wikipedia customs being applied here, people make collections or categories using relations, for example cycle network North-Rine-Westphalia containing every cycle route in that part of Germany, or another relation containing every German Autobahn, or one containing all McDonald's restaurants. Nice. Much of this I suspect is because people really, really don't understand the spatial bit of spatial databases. We still have strong proponents of is_in style tagging on every object in a town, when the more sane way to do that is to delineate the town itself and use some spatial maths. Ditto with spatial-collections like All X in area Y, which is utterly redundant. Sure, if you do have a border around the towns, and borders around the countries, and all other kinds of border data... Sometimes, you only know that this place is in that other place, but there is no free data to derive borders from. And you can't trace political / administrative boundaries from Yahoo imagery, can you? Regards, Hakan -- The key to immortality is first living a life worth remembering... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] arbitrariness of relations [was: HEADS UP osmosis pgsql schema users]
On Tue, Nov 4, 2008 at 1:02 PM, Raphaël Jacquot [EMAIL PROTECTED] wrote: Matt Amos wrote: ah, you mean intelligent design? no no, the giant spaghetti monster ;) Ahem. That's *Flying* Spaghetti Monster. Thou shalt not take the name of Flying Spaghetti Monster in vain. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
Richard Fairhurst schrieb: Erik Johansson wrote: This is a really naive and contraproductive argument, nothing is black and white. You have to define what it is you are mapping, and you don't do that in the database. Yeah, but therein lies the problem. The people doing the defining are, in many cases, not the ones who are doing the mapping. There are plenty of people voting on things just because they like voting. If people refrained from discussing and voting unless they had _personally_ come up against the problem that the proposal was aiming to solve, I think the process would have a lot more respect. H, How do you know, that: The people doing the defining are, in many cases, not the ones who are doing the mapping ?!? BTW: It's simply a misconception that the voting process necessarily needs that all people involved to be experts of the topic. If the proposal is well prepared and discussed even by a very small number of people knowing what they are talking about, you will - even as an outsider - get a good idea if the feature is a good thing or not. Regards, ULFL ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
On 4 Nov 2008, at 20:56, Ulf Lamping wrote: It's simply a misconception that the voting process necessarily needs that all people involved to be experts of the topic. If the proposal is well prepared and discussed even by a very small number of people knowing what they are talking about, you will - even as an outsider - get a good idea if the feature is a good thing or not. Surely the only voting process that carries any weight in the long run is people actually using a given key/value pair in the database... Why not just provide a list of popular tags (like map_features does now), and a long list of possibilities for things not on the 'popular' list (basicly what the Proposed_features currently do). Any proposed features that see significant real world usage make there way onto the map_features page. -- Chris Jones, SUCS Admin http://sucs.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database
Hi Chris, Chris Jones wrote: Surely the only voting process that carries any weight in the long run is people actually using a given key/value pair in the database... If the long run building of the map is done following guidelinse posted by the wiki docs in the short run, then I would say that the wiki matters. In our case, we have users who will want to know how do we do this (this being add data to OSM such that the applications they care about will be able to use it). So as an author of a client app I can either: - Let them enter whatever they want and try to make sense of it later or - Provide some guidance on the wiki and then compare that to actual use. In other words, the wiki strikes me as a way for app developers and map makers to communicate ahead of time, saving a lot of potential waste. cheers ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ X-Plane Wiki: http://wiki.x-plane.com/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database
Hi, Ben Supnik wrote: So as an author of a client app I can either: - Let them enter whatever they want and try to make sense of it later or - Provide some guidance on the wiki and then compare that to actual use. Our eternal argument on this list revolves around the fact that those who write on the Wiki and those who write client apps are disjunct groups of people, with the application writers doing what they want (it's their spare time after all) and the Wiki contributors assuming that they just have to cast a vote and the world will listen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Compile Error in josm-ng
I have problems building the debian Package because of a Compile Problem in josm-ng. Please can someone fix this. Thanks Joerg - Compile Josm-ng BUILD SUCCESSFUL Total time: 0 seconds [javac] /home/tweety/svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/ui/Position.java:89: setCenter(org.openstreetmap.josmng.view.ViewCoords) is not public in org.openstreetmap.josmng.view.MapView; cannot be accessed from outside package [javac] mv.setCenter(mv.getProjection().coordToView(new CoordinateImpl(lat,lon))); [javac] ^ [javac] Note: /home/tweety/svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/utils/BackgroundTask.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 error BUILD FAILED /home/tweety/svn.openstreetmap.org/applications/editors/josm-ng/nbproject/build-impl.xml:325: The following error occurred while executing this line: /home/tweety/svn.openstreetmap.org/applications/editors/josm-ng/nbproject/build-impl.xml:158: Compile failed; see the compiler error output for details. -- Jörg (Germany, Tettnang) http://www.ostertag.name/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
COn Tue, Nov 4, 2008 at 6:16 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: Erik Johansson wrote: This is a really naive and contraproductive argument, nothing is black and white. You have to define what it is you are mapping, and you don't do that in the database. Yeah, but therein lies the problem. The people doing the defining are, in many cases, not the ones who are doing the mapping. There are plenty of people voting on things just because they like voting. If people refrained from discussing and voting unless they had _personally_ come up against the problem that the proposal was aiming to solve, I think the process would have a lot more respect. Real mappers don't document; their tags are enough. Wannabe mappers read documentation and follow templates. So how should you become a mapper if there is no documentation. There is a lack of people who are willing to write something on the wiki, not too many. Sure the wiki doesn't really define the database, it tells people how to tag stuff and that is a lot more important than anything else. BTW, This is still on dev because dev is where the wiki FUD flows deepest. Regards Erik. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
On Tue, Nov 4, 2008 at 10:46 PM, Erik Johansson [EMAIL PROTECTED] wrote: COn Tue, Nov 4, 2008 at 6:16 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: The people doing the defining are, in many cases, not the ones who are doing the mapping. There are plenty of people voting on things just because they like voting. If people refrained from discussing and voting unless they had _personally_ come up against the problem that the proposal was aiming to solve, I think the process would have a lot more respect. Real mappers don't document; their tags are enough. Wannabe mappers read documentation and follow templates. So how should you become a mapper if there is no documentation. There is a lack of people who are willing to write something on the wiki, not too many. there have been occasions when real mappers have documented their tags on the wiki, only to have the wiki pages overwritten by someone else's better ideas. maybe this puts some people off? Sure the wiki doesn't really define the database, it tells people how to tag stuff and that is a lot more important than anything else. you're absolutely right - the wiki should help document the database and help spread knowledge of tagging culture. maybe we should be encouraging wannabe mappers to look for tags on tagwatch and, with the help of the mailing lists / IRC / local meet-ups, document them on the wiki? cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
Chris Jones schrieb: On 4 Nov 2008, at 20:56, Ulf Lamping wrote: It's simply a misconception that the voting process necessarily needs that all people involved to be experts of the topic. If the proposal is well prepared and discussed even by a very small number of people knowing what they are talking about, you will - even as an outsider - get a good idea if the feature is a good thing or not. Surely the only voting process that carries any weight in the long run is people actually using a given key/value pair in the database... Yes and no. It's not a good idea to simply assume that the database is enough. The database only carries the syntax. It can tell you what tags people use. However, it can not tell you the semantic of the tag - what people meant. As this seems pretty obvious at a glance it's unfortunately not that easy. There is lot's of examples of these confusions: landuse=forest vs. natural=wood From simply looking at both tags, it's just not possible to be sure about the differences. In fact at least here in germany since recently a lot of people weren't even aware that there are two such tags and that there are differences what they mean. There are a lot more examples about these confusions, and without documenting the tags this will continue. Why not just provide a list of popular tags (like map_features does now), and a long list of possibilities for things not on the 'popular' list (basicly what the Proposed_features currently do). We call that tagwatch: http://tagwatch.stoecker.eu/Europe/En/index.html ;-) Any proposed features that see significant real world usage make there way onto the map_features page. Well, I've recently added some often used tags indicated by tagwatch to the Map Features page. It wasn't easy for me to write a good tag description, as I couldn't get it from the database or any proposals. There are still some tags that are in significant use that I didn't added to Map Features, just because I wasn't sure what they really meant ... Regards, ULFL ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
On Wed, Nov 5, 2008 at 12:27 AM, Ulf Lamping [EMAIL PROTECTED] wrote:
Any proposed features that see significant real world usage make there
way onto the map_features page.
Well, I've recently added some often used tags indicated by tagwatch to
the Map Features page. It wasn't easy for me to write a good tag
description, as I couldn't get it from the database or any proposals.
There are still some tags that are in significant use that I didn't
added to Map Features, just because I wasn't sure what they really meant ...
Perhaps extract users using this tag from the extended API download,
and mail them?
I've included a hack that does that, but osmxapi includes all lots of
extra data you don't need so it's abit slow. Example:
perl UserStat.pl FIXME survey
user:usage
emj:49
maning:3
JeolF:1
Kekoil:1
casualwalker:1
$k=$ARGV[0];
$v=$ARGV[1];
die(Usage $0 tag key tag value) if($k eq || $v eq );
open(XAPI, curl 'http://xapi.openstreetmap.org/api/0.5/way\\[$k=$v\\]'|);
while(XAPI){
$user= $1 if(/ user=.([^']+)/);
$stat{$user}+=1 if(/k=.FIXME. v=.survey./);
}
print user:usage\n;
foreach $user (sort {$stat{$b} = $stat{$a} } keys %stat){
print $user:$stat{$user}\n
}
/Erik
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
On Wed, Nov 5, 2008 at 12:26 AM, Matt Amos [EMAIL PROTECTED] wrote: On Tue, Nov 4, 2008 at 10:46 PM, Erik Johansson [EMAIL PROTECTED] wrote: COn Tue, Nov 4, 2008 at 6:16 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: The people doing the defining are, in many cases, not the ones who are doing the mapping. There are plenty of people voting on things just because they like voting. If people refrained from discussing and voting unless they had _personally_ come up against the problem that the proposal was aiming to solve, I think the process would have a lot more respect. Real mappers don't document; their tags are enough. Wannabe mappers read documentation and follow templates. So how should you become a mapper if there is no documentation. There is a lack of people who are willing to write something on the wiki, not too many. there have been occasions when real mappers have documented their tags on the wiki, only to have the wiki pages overwritten by someone else's better ideas. maybe this puts some people off? Yes that is very cumbersome but how often does this happen, and does it really warrant that flippant attitude? Having a better way to handle multiple meanings of tags might help. But perhaps Frederik is right maybe it's just too much work to translate wiki preferences automatically to JOSM, potlatch templates (also stylesheets for Osmarender and Mapnik to take the common complaint from people who wants new tags). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
Hi, Erik Johansson wrote: Yes that is very cumbersome but how often does this happen, and does it really warrant that flippant attitude? Having a better way to handle multiple meanings of tags might help. The core of this flippant attitude is easily explained. When OSM was started - that was before my time, so I'm just telling other people's stories here - it was not the only collaborative mapping project around. Other, competing projects started out by first trying to set up a good tagging scheme (an ontology as people say) for everything, and never got far beyond that. OpenStreetMap didn't bother, and just started mapping - differentiating, initially, only between railway, waterway and highway and that was it. Things evolved from there to where we are now; OSM has swept away anything remotely comparable. Like many computer people, my instinct is to do exactly what the failed projects have done; it is what you are taught at uni or in the workplace: Analyse problem, make data model, acquire data, process data. OpenStreetMap managed to largely skip the initial phases, going against perceived wisdom, and it worked out well. Now, with the ever larger influx of new people to the project, this perceived wisdom, this how things are usually done, comes in through the back door. There's not a single day where you don't hear somebody say but we need a unified tagging scheme, everybody needs to adhere to the same standard, it will never work otherwise, the data will be useless unless everybody means the same. (But it will never work is something that has been said about OSM from day one.) Things that are special about OSM, things that have been OSM's strengths in the past, are often unreflectedly discounted as weaknesses by these newcomers: Any database must ... blah blah blah ... lest it is completely useless. There are two possibilities: 1. OpenStreetMap did the right thing initially, but what was the right thing *then* is not the right thing *now* anymore; we really need strict standards, a body to govern them, a dictionary of approved tags, and editors that will only allow you to tag things differently if you press I am sure three times. That is, as far as I can see, the model that Google's Map Maker uses. 2. OpenStreetMap is really different from anything else, the usual rules do not apply, and trying to apply perceived wisdom to OSM will break what is precious about it. The people calling for standards, rules, unified tagging and all that are just not flexible enough; they think they know what works and what doesn't, and fail to see that OSM is a different environment to which they cannot simply transport their experiences from the workplace or from software projects or from Wikipedia. I tend to assume that 2. is correct and I also tend to make fun of those who, I like to think, cannot adapt their brains to something that works differently. But it is very well possible that I am wrong, or that at least situation 1. will be true at some time in the near future. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database (was: relations)
Third possibility... I think that crrowd sourcing itself is actually different (in general and not just OSM being different). In the case of OSM we clearly see emergent 'standards' and 'models, These are codefied in the wiki and, more importantly, in the tools that realize the data into maps, routes, geo-coded results etc. Editors want their data on maps (and routes etc.) and so try to make it useful and findable (just like photo taggers are trying to get their photos found). And they share information about how to do it in the wiki. The wiki emerges from the practices of the community AND serves as a reference point to document and debate/discuss these. In the end the apps developers who realize the data will use the most descriptive and useful methods that exist in the data and participate in the wiki and mail list debate on best practices. They reward the most useful and used models by showing that data. (Hence a good address finder will show what is tagged to it's understanding and the crowd will move to tag that way - or reject it and up will pop new address finders. And evolution continues.) The genius of a good crowd sourced project (and OSM is very good) is that the data being sourced AND the encoding model itself are BOTH crowd sourced. This fuels the evolution. When you think about it, it is the obvious thing to do, but then, most really good ideas are both simple and obvious in retrospect. Cheers, Jim Brown -CTO CloudMade (Sent from my iPhone) On 5 Nov 2008, at 02:36, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, Erik Johansson wrote: Yes that is very cumbersome but how often does this happen, and does it really warrant that flippant attitude? Having a better way to handle multiple meanings of tags might help. The core of this flippant attitude is easily explained. When OSM was started - that was before my time, so I'm just telling other people's stories here - it was not the only collaborative mapping project around. Other, competing projects started out by first trying to set up a good tagging scheme (an ontology as people say) for everything, and never got far beyond that. OpenStreetMap didn't bother, and just started mapping - differentiating, initially, only between railway, waterway and highway and that was it. Things evolved from there to where we are now; OSM has swept away anything remotely comparable. Like many computer people, my instinct is to do exactly what the failed projects have done; it is what you are taught at uni or in the workplace: Analyse problem, make data model, acquire data, process data. OpenStreetMap managed to largely skip the initial phases, going against perceived wisdom, and it worked out well. Now, with the ever larger influx of new people to the project, this perceived wisdom, this how things are usually done, comes in through the back door. There's not a single day where you don't hear somebody say but we need a unified tagging scheme, everybody needs to adhere to the same standard, it will never work otherwise, the data will be useless unless everybody means the same. (But it will never work is something that has been said about OSM from day one.) Things that are special about OSM, things that have been OSM's strengths in the past, are often unreflectedly discounted as weaknesses by these newcomers: Any database must ... blah blah blah ... lest it is completely useless. There are two possibilities: 1. OpenStreetMap did the right thing initially, but what was the right thing *then* is not the right thing *now* anymore; we really need strict standards, a body to govern them, a dictionary of approved tags, and editors that will only allow you to tag things differently if you press I am sure three times. That is, as far as I can see, the model that Google's Map Maker uses. 2. OpenStreetMap is really different from anything else, the usual rules do not apply, and trying to apply perceived wisdom to OSM will break what is precious about it. The people calling for standards, rules, unified tagging and all that are just not flexible enough; they think they know what works and what doesn't, and fail to see that OSM is a different environment to which they cannot simply transport their experiences from the workplace or from software projects or from Wikipedia. I tend to assume that 2. is correct and I also tend to make fun of those who, I like to think, cannot adapt their brains to something that works differently. But it is very well possible that I am wrong, or that at least situation 1. will be true at some time in the near future. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23 '33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev
Re: [josm-dev] JOSM language plugins and stable version?
On Tue, 4 Nov 2008, Stefan Baebler wrote: On Tue, Nov 4, 2008 at 8:28 AM, Dirk Stöcker [EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, Florian Schmitt wrote: it seems that the lang-* plugins aren't available any more. This means that new users who want to use the last stable version 1010 aren't able to change the language of JOSM. I think as long as a stable version is recommended, the localisation plugins should be available, even if they're not necessary for the latest build. Would it be possible to provide the lang-Plugins again? I updated the stable to 1065. but this stable is also missing translations until build script is adjusted so that the jar includes translations. Is it? I downloaded and tested before switching. Probably you have a yesterdays 1065? :-) Sorry, but there was no change yesterday, so the number was not increased. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
