[OSM-dev] /cgi-bin/export in svn?
where is http://www.openstreetmap.org/cgi-bin/export in svn? thanks mikel ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] /cgi-bin/export in svn?
http://svn.openstreetmap.org/sites/tile.openstreetmap.org/cgi-bin/export / Grant On 10/10/09, Mikel Maron mikel_ma...@yahoo.com wrote: where is http://www.openstreetmap.org/cgi-bin/export in svn? thanks mikel ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Sent from my mobile device ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Gosmore not Public Domain anymore?
2009/10/1 Christian Müller cmu...@gmx.de: snip Will gosmore stay PD and, if not, what license will it be licensed under in the future? PD Confirmed http://trac.openstreetmap.org/changeset/18055 I've modified the code quite a bit - is there any chance on getting svn access / do you accept changes? I'm happy to greate the SVN account, contact me off list with your preferred username. Code changes with Gosmore, likely best discussed directly with Nic Roets. / Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 3d Import into OpenArena working
Hello, I think, the future will not be Blender or any gaming engine like openarena. I think, the most used platform will be WebGL, a 3D-rendering API integrated in the browsers, usable with JavaScript. It is already integrated in developer versions of WebKit (Safari, Konqueror) and Firefox. Original-Nachricht Von: jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com Well, I have started on this already Lets just focus on blender as a modeling tool to begin with. There are many other usages for blender models. and the model is basically blender. I hope to in the next step find some good python based rendering code and just get that to work in blender to create 2d models in blender of the objects and then make them 3d by adding in simple infomation. I dont know about scaling, but I can say that for the purposes of gaming, you dont want the maps to be too big. When we get the ability to export to blender in higher quality then belive me, the gaming kiddies will do the porting for you. mike -- Diplom-Informatiker, Homepage: http://www.stefanziegler-online.de/ Wir alle wissen mehr als das, wovon wir wissen, dass wir es wissen. (Thornton Wilder) GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 3d Import into OpenArena working
What about vrml? And blender is an editor. What editor will you use to produce webgl? Blender On Sun, Oct 11, 2009 at 12:46 AM, Stefan Ziegler stefan.ziegler_...@gmx.de wrote: Hello, I think, the future will not be Blender or any gaming engine like openarena. I think, the most used platform will be WebGL, a 3D-rendering API integrated in the browsers, usable with JavaScript. It is already integrated in developer versions of WebKit (Safari, Konqueror) and Firefox. Original-Nachricht Von: jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com Well, I have started on this already Lets just focus on blender as a modeling tool to begin with. There are many other usages for blender models. and the model is basically blender. I hope to in the next step find some good python based rendering code and just get that to work in blender to create 2d models in blender of the objects and then make them 3d by adding in simple infomation. I dont know about scaling, but I can say that for the purposes of gaming, you dont want the maps to be too big. When we get the ability to export to blender in higher quality then belive me, the gaming kiddies will do the porting for you. mike -- Diplom-Informatiker, Homepage: http://www.stefanziegler-online.de/ Wir alle wissen mehr als das, wovon wir wissen, dass wir es wissen. (Thornton Wilder) GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Remove internal help browser?
Regarding this F1 thing - no one will get it. Best you can do is put some big inviting help button on the dialog that might need explanation. I already started to do that. See the new help aware option pane http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/gui/He lpAwareOptionPane.java and two examples I've migrated http://josm.openstreetmap.de/wiki/Help/Concepts/Conflict I plan to do the same thing in the message dialog for error messages created by the server, see http://josm.openstreetmap.de/ticket/2882 Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Sebastian Klein Gesendet: Freitag, 9. Oktober 2009 21:45 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Remove internal help browser? Karl Guggisberg wrote: Hi, I plan to remove JOSMs internal help browser and to always delegate to an external browser, for two reasons: Good idea. Having an internal browser for help seems quite strange and old-fashioned to me. Also, the current version is far from usable. Nowadays, if there is some problem, you open a browser and google it. If it isn't answered in some forum immediately, you will at least find the documentation and try to resolve it there. Regarding this F1 thing - no one will get it. Best you can do is put some big inviting help button on the dialog that might need explanation. (But only if there is some documentation available.) It's quite pointless to press F1 and get an empty page each time. Dirk Stöcker wrote: Yes. External browsers have too many drawbacks regarding visibility and launching. If you do not like the internal one, then make it configurable to disable it. So many applications do this browser launch thing, it can't be that awful. Cheers, Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Remove internal help browser?
Karl Guggisberg wrote: Hi, I plan to remove JOSMs internal help browser and to always delegate to an external browser, for two reasons: Consider mapping in remote areas using portable device such as netbook. 1) Download appropriate area using josm and save osm file. 2) Collect gps data until handheld gps device full: at end of day (in tent?) transfer tracks from gps to netbook. Edit local osm file using josm. No net connection. 3) Iterate for several days. [osm editing is best done while memory fresh, and area can be checked if problems..] Some form of local help for josm is really needed in such cases. ael ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] unmaintained plugins
On Sat, 10 Oct 2009, MP wrote: Before someone deleted it from the plugins page (so it WAS available through official JOSM plugin update system and it was pointing to corrent URL with newest and working version) it was maintained and perfectly working. I wonder how someone have discovered that is is unmaintained? Because we got lots of bugreports which showed that the plugin was not actively developed for a long time now. I think best would be to remove this feature and let users decide which plugins they want to use. I introduced this check to get rid of plugins which are no longer working. Most users aren't able to decide, so JOSM needs to do this for him. And a lot of users install ALL plugins without thinking if they need them or not. Changing the warning to use a don't bug me again dialog would be possible. But this issue is seldom, so it is probably not worth the effort. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Two patches for the Validator plugin
Hi, Sorry if I am giving the impression of being too impatient, but I have submitted two patches on Trac. As an outsider or hang-around member of the JOSM developer community, I am not familiar with the workflow. Will the Trac tickets containing the patches be eventually accepted or rejected by someone, or would it be better to send reminders on this list? Or should I look up the owner of a component somewhere and bug the owner directly? The patches in question are these two, both for the Validator plugin: http://josm.openstreetmap.de/ticket/3412 Check for missing name:* translations http://josm.openstreetmap.de/ticket/3669 NodesWithSameName with unique ref The latter (#3669) suppresses bogus nodes with same name warnings for bus stops and other nodes that carry a unique ref tag. Dirk already replied that the whole check should be dropped, but I think that it is useful. Best regards, Marko (user Skela) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] unmaintained plugins
On Sat, 10 Oct 2009, MP wrote: Also, i think this feature as it is is quite stupid - if you want to use some of the unmaintained plugins (if that plugin is still working, which is the case of mutipoly), there should be some checkbox don't remind me for this plugin again, otherwise you'll see this message every time you start JOSM. I think current exception handling in plugin is enough - when plugin causes exception, there is possibility to disable it. Plugins that do not work cause exception and gets disabled by the user. Ah I forgot. Most plugins use a nonstandard naming, so JOSM will not be able to detect the plugin. The plugin multipoly is one of them. I'm currently changing the code in JOSM which detects if a plugin was the reason for problems. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] unmaintained plugins
Ah I forgot. Most plugins use a nonstandard naming, so JOSM will not be able to detect the plugin. The plugin multipoly is one of them. Nonstandard naming? Which naming of what (name of class? name in manifest? some other name?) is standard and what should I change in the plugin to fix this? Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Two patches for the Validator plugin
http://josm.openstreetmap.de/ticket/3412 Check for missing name:* translations So this is patch which adds another check in validator. This reminded me of one idea - that validator plugin could have plugins itself. Currently if you want to add new test, you write new class and then you open OSMValidatorPlugin.java, find line with public static ClassTest[] allAvailableTests = new Class[] and add your test to the list. And then you can either wait for the check to be added to validator or compile your version for yourself. Perhaps if such extra checks could be packaged as separate plugin (which would require validator as dependency), then if would be easier to have some check specific to only small group of people (like writing specific check for some data that are used only in some country - for example some TIGER-specific checks are useful only for people editing data in the USA, etc ...) since these probably won't get to validator in SVN Only things that would need to be resolved for that would be enforcing plugin dependencies (that could be done at runtime in worst case) and allowing plugins to interact with each other, so the new check could add itself in validator. Something like: Validator v=(Validator)Main.getPlugin(validator); if (v=null) error(validator required); if (v.getVersion()12345) error(too old validator version); v.addCheck(VerySpecialCheck.class); v.addCheck(AnotherSpecialCheck.class); Perhaps the dependency checking could be done in plugin manifest: Plugin-name: validator-extra-check Depends: validator=12345 What is the oppinion on this? Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] unmaintained plugins
On Sat, 10 Oct 2009, MP wrote: Ah I forgot. Most plugins use a nonstandard naming, so JOSM will not be able to detect the plugin. The plugin multipoly is one of them. Nonstandard naming? Which naming of what (name of class? name in manifest? some other name?) is standard and what should I change in the plugin to fix this? JOSM till some minutes ago only recogniced org.openstreetmap.josm.plugins.pluginname.xxx as classname when detecting plugins for bug reports. Now all pathnames are recogniced (when at least one individual path-part exists). I changed these few plugins which did not work (i.e. used a common path like or org.openstreetmap.josm.plugins). Didn't test for multipoly, but as the path is multipoly.xxx, it should be working now. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Two patches for the Validator plugin
On Sat, 10 Oct 2009, MP wrote: Only things that would need to be resolved for that would be enforcing plugin dependencies (that could be done at runtime in worst case) and allowing plugins to interact with each other, so the new check could add itself in validator. Something like: Validator v=(Validator)Main.getPlugin(validator); if (v=null) error(validator required); if (v.getVersion()12345) error(too old validator version); v.addCheck(VerySpecialCheck.class); v.addCheck(AnotherSpecialCheck.class); Perhaps the dependency checking could be done in plugin manifest: Plugin-name: validator-extra-check Depends: validator=12345 What is the oppinion on this? We already have a way for Plugin dependencies (e.g. surveyor uses this): attribute name=Plugin-Requires value=livegps/ The version test does not yet exist, but could be added when required. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
