Re: [osmosis-dev] getting all the relations from source with completeRelations=yes
Frederik Ramm wrote about similar issues on January 9 (not sure if they're the same though). I haven't had a chance to look into them yet. I didn't write the completeRelations, completeWays functionality so I don't understand how they work at the moment. It's on my TODO list, but I'm finding it hard to get the time. If somebody else has the time to look into that area of the code I'd be very grateful ;-) Brett On Wed, Mar 10, 2010 at 10:30 AM, Maxim Dubinin s...@gis-lab.info wrote: Hi all, to follow up on http://www.mail-archive.com/osmosis-dev@openstreetmap.org/msg00279.html I'm using 0.34 and I'm doing: osmosis --read-xml file=input.osm --bounding-polygon file=bnd.poly completeWays=yes completeRelations=yes idTrackerType=BitSet --write-xml file=output.osm As a result, I'm having _all_ relations (more that 16 thousands) from input.osm dumped into output.osm. All these extra relations are empty ones, ways and nodes are not extracted. According to wiki: completeRelations Include all available relations which are members of relations which have at least one member in the bounding box. But some of extracted ones definitely do not have any members in bnd.poly. Any ideas? Maxim ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [OSM-dev] Suggested development server
On 9 Mar 2010, at 03:55, Thomas Emge wrote: I am in the process of developing an editing client for OpenStreetMap and I would like to know what is the suggested way to post edits during in the software development phase. Knowing my dev talent I am suspecting that I might issue a couple of malformed diff changesets ;) Is http://api06.dev.openstreetmap.org/ an appropriate entity to use? Yes. That's specifically what api06.dev was setup for. Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] New beta of khtml map online
hi all There is a new version of my map online: http://www.khtml.org/iphonemap/ The library is free software. It's still work in progress, but should give you a first impression. Please try a webkit browser (Chrome, Safari,...). Firefox does not support hardware accelerated image zoom and is much slower. As a next step I'm looking for a home for this project. I don't really like sourceforge. It tried to use google code, but no success to start a project there. What's the best opensource site at the moment? It should have mailinglist, svn, bugtracking,... Please have a look at the API. It's easy to change it now. Later it will be not so easy if projects depend on it. Open Issues: There are many bugs. It makes not much sense to report this bugs at the moment. When I have a bugtracking system, you are welcome to do so. br/ The input field for search is not editable at chrome(linux). You can only search for wien. If you know why it's not editable please contact me. br/ br/ There is one thing I can't solve. It's the mousewheel speed. On some systems the zoom is too fast on other systems the zoom is too slow. This depends on OS, browser and maybe usersettings. If you have an idea how to solve that, please tell me. Feedback There is a feedback form at the help.php page. If you have usability ideas please post. Payed support If you need a special feature for the lib, please contact me. I will continue to develop this map lib, but money can make the development much faster. thanks Bernhard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New beta of khtml map online
On 9 Mar 2010, at 08:49, Bernhard zwischenbrugger wrote: As a next step I'm looking for a home for this project. I don't really like sourceforge. It tried to use google code, but no success to start a project there. What's the best opensource site at the moment? It should have mailinglist, svn, bugtracking,... Github is the current craze. Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New beta of khtml map online
On 09/03/2010, at 10.30, Shaun McDonald wrote: On 9 Mar 2010, at 08:49, Bernhard zwischenbrugger wrote: As a next step I'm looking for a home for this project. I don't really like sourceforge. It tried to use google code, but no success to start a project there. What's the best opensource site at the moment? It should have mailinglist, svn, bugtracking,... Github is the current craze. Another option is http://launchpad.net, it is based on Bazaar, and has very nice tools for bugtracking, mailing lists, milestone tracking and even a rudamentary homepage for your project. -- Morten ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New beta of khtml map online
hi Looks good! fast in chromium on my desktop - any plans to get it working with Android? Also, WMS layers and opacity? If Android Browser gets multitouch support, it should work there. Android Browser has no SVG, no 3D CSS so it will be slow on Android. At the moment the question is if Android will support that kind of browser maps. Bernhard Cheers, Tim On 9 March 2010 08:49, Bernhard zwischenbrugger b...@datenkueche.com wrote: hi all There is a new version of my map online: http://www.khtml.org/iphonemap/ The library is free software. It's still work in progress, but should give you a first impression. Please try a webkit browser (Chrome, Safari,...). Firefox does not support hardware accelerated image zoom and is much slower. As a next step I'm looking for a home for this project. I don't really like sourceforge. It tried to use google code, but no success to start a project there. What's the best opensource site at the moment? It should have mailinglist, svn, bugtracking,... Please have a look at the API. It's easy to change it now. Later it will be not so easy if projects depend on it. Open Issues: There are many bugs. It makes not much sense to report this bugs at the moment. When I have a bugtracking system, you are welcome to do so. br/ The input field for search is not editable at chrome(linux). You can only search for wien. If you know why it's not editable please contact me. br/ br/ There is one thing I can't solve. It's the mousewheel speed. On some systems the zoom is too fast on other systems the zoom is too slow. This depends on OS, browser and maybe usersettings. If you have an idea how to solve that, please tell me. Feedback There is a feedback form at the help.php page. If you have usability ideas please post. Payed support If you need a special feature for the lib, please contact me. I will continue to develop this map lib, but money can make the development much faster. thanks Bernhard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] debugging #4669.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Can someone please tell me what I can do to help debugging this bug: https://josm.openstreetmap.de/ticket/4669 I have the session still running. skyper -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEAREIAAYFAkuWNZoACgkQalWTFLzqsCsSDACTBncer3fjEYIGQcq9OyrBXp8f VQCeIPCY/nS8rbF0gT+N8dCxGLxsBMQ= =WHCc -END PGP SIGNATURE- ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Function to select or download a sequence of ways?
Marko, XAPI does exactly what you need. insert your bounding box ... wget http://www.informationfreeway.org/api/0.6/way\[natural=coastline\]\[bbox=…\] -O coastline.osm On 9 Mar 2010, at 1:59 , Marko Mäkelä wrote: Hi Karl, thank you for your helpful reply. As a further development, it could be useful to create a selective download function (follow this way until reaching a branch or a given bounding box). ... except for this function which sounds like what the waydownloader plugin provides. Great, I will have to check it. It could be a useful starting point for my work. One more question: is there a function that would extend the current selection to the given direction? For example, if I have selected a coastline, add all islands west of the selection to the selection. In that way, I would see if there are any natural=coastline objects in the mainland. Or one could use such a function when producing a map of a city or suburb and wanted to delete all objects outside the borders. (Yes, I know that Osmosis could do such things, but a GUI could be nicer.) Marko ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Hack day
On 8 March 2010 18:15, SteveC st...@asklater.com wrote: Thanks Tom, I've added the 14th at the bottom of that page and linked it from the calendar. Hope people can come. I'll be along too - Steve, the wiki page says to call you for access to the building. I assume this is your listed UK number? Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Google Summer of Code Projects
Just a little bump to us that applications are open for organisations to apply, and we have 3 days left. http://google-opensource.blogspot.com/2010/03/google-summer-of-code-applications-now.html Tim On 28 February 2010 19:05, Graham Jones grahamjones...@googlemail.com wrote: Hi There, It will soon be time for OpenStreetMap to apply to join the 2010 Google Summer of Code Programme. This gives students the opportunity to work on open source projects during the summer, for which they receive some payment by Google. It costs us nothing more than providing a Mentor to guide the student. It would be really useful if we could put together a list of potential student projects to get potential applicants thinking. The projects need to be fairly well defined to make it easy to judge 'success', so it is good to have specific targets. From recent discussions on these lists I have identified the following possibilities so far: Develop a stand alone 'Newbie'/'Introductory'/'Lite' Editor - the priority is ease of use rather than functionality. Help with the development of Potlatch 2 (maybe to include the 'lite' editor functionality) - we would need to help the applicants identify specific targets. Develop a simple 'mapping tool' for mobile phones to easily collect GPX traces, geotagged images and geotagged audio clips. Ideally it should be capable of running on both Android, J2ME and Iphones, so you can have the same simple application no matter what sort of phone you use. Improve the usability of a simple mobile phone map editing application (such as vespucci for android). Incorporation of OSM data and traffic data. I am sure there are other things that I am not familiar with too - would it be useful for someone to do some work on tools to process OSM data in some way, or are there any tasks on the OSM server itself that could be turned into projects? Please will you give some thought to other possibilities and either add them to the GSoC 2010 Wiki Page (http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2010) or reply by email if you prefer. Thanks Graham. -- Graham Jones Hartlepool, UK email: grahamjones...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] how does the transition to tested work ?
On Tue, 9 Mar 2010, Matthias Julius wrote: Be careful with this. It should only be offered for simple conflicts. What is a simple conflict? Maybe a count would be useful: + each added tag = 1 point + each removed tag= 1 point + changed tag = 5 points + slightly changed coordinate = 1 point + big coordinate change = 10 points + ... Simple conflict is = 5 points A graphical visualization of both sides of conflicts would help. Yes. THAT would really be fine. A class to display a subset of the database in an own widget would be very helpful! There are multiple places in JOSM were we could use that. With lots of reworking done regarding data storage maybe it is possible to do that now. And best would be if selection does also work for this. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Tirex - a renderd alternative
Op 09-03-10 14:07, Jochen Topf schreef: As long as you are on the same host and don´t fill up the buffer UDP is reliable. The whole thing works only on the same host anyway, so this should not be a problem. The same host thing is not what my future is. The idea of multiple render services that can be balanced by the webserver is. But since it is now also unknown if one could actually connect to a remote tile service, I would bias for TCP. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New beta of khtml map online
Looks good! fast in chromium on my desktop - any plans to get it working with Android? Also, WMS layers and opacity? Cheers, Tim On 9 March 2010 08:49, Bernhard zwischenbrugger b...@datenkueche.com wrote: hi all There is a new version of my map online: http://www.khtml.org/iphonemap/ The library is free software. It's still work in progress, but should give you a first impression. Please try a webkit browser (Chrome, Safari,...). Firefox does not support hardware accelerated image zoom and is much slower. As a next step I'm looking for a home for this project. I don't really like sourceforge. It tried to use google code, but no success to start a project there. What's the best opensource site at the moment? It should have mailinglist, svn, bugtracking,... Please have a look at the API. It's easy to change it now. Later it will be not so easy if projects depend on it. Open Issues: There are many bugs. It makes not much sense to report this bugs at the moment. When I have a bugtracking system, you are welcome to do so. br/ The input field for search is not editable at chrome(linux). You can only search for wien. If you know why it's not editable please contact me. br/ br/ There is one thing I can't solve. It's the mousewheel speed. On some systems the zoom is too fast on other systems the zoom is too slow. This depends on OS, browser and maybe usersettings. If you have an idea how to solve that, please tell me. Feedback There is a feedback form at the help.php page. If you have usability ideas please post. Payed support If you need a special feature for the lib, please contact me. I will continue to develop this map lib, but money can make the development much faster. thanks Bernhard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hack day
good point - no the US one. On Mar 9, 2010, at 7:34 AM, Dermot McNally wrote: On 8 March 2010 18:15, SteveC st...@asklater.com wrote: Thanks Tom, I've added the 14th at the bottom of that page and linked it from the calendar. Hope people can come. I'll be along too - Steve, the wiki page says to call you for access to the building. I assume this is your listed UK number? Dermot -- -- Iren sind menschlich Yours c. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New beta of khtml map online
Shaun McDonald schrieb: On 9 Mar 2010, at 08:49, Bernhard zwischenbrugger wrote: As a next step I'm looking for a home for this project. I don't really like sourceforge. It tried to use google code, but no success to start a project there. What's the best opensource site at the moment? It should have mailinglist, svn, bugtracking,... Github is the current craze. I added the project to github. http://github.com/robotnic/khtmlib But I can't find a bugtracker there. Bernhard Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - a renderd alternative
Op 09-03-10 08:46, Frederik Ramm schreef: But Stefan, you are of course welcome to modify your mod_tile version to talk to Tirex directly. The protocol is really most simple, you just have to send one UDP message and wait for an answer. The wait for an answer part, how can your 'rely' on that with UDP? Or is your idea to that if your timeout expires, than serve a busy tile? Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - a renderd alternative
Directly some other issue; since we also have modified Renderd (extensively), can I suggest some features to you too? - Meta tile rendering, but not storing it as meta tile. http://trac.openstreetmap.org/ticket/2653 - Per layer image settings http://trac.openstreetmap.org/ticket/2654 Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Plugins not working with 3094 and Linux ?
Hi, I received already two complains about 3094 and the cadastre-fr plugin not working on Linux (ubuntu or Debian Etch) with a java6 env. Exception is : java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) Do we have to modify the ant files and recompile all plugins for Java6 ? Strange is that it works fine on Windows. Pieren ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] how does the transition to tested work ?
Dirk Stöcker openstreet...@dstoecker.de writes: On Mon, 8 Mar 2010, Matthias Julius wrote: This is a major issue which I think should be adressed soon. It won't replace the current feature for resolving an individual conflict, but it should complete it with better support for mass resolution. Since a while I have been thinking adding Take mine and Take theirs to the context menu of the conflict list dialog. Even quicker would be if the conflict list dialog had buttons for this. Be careful with this. It should only be offered for simple conflicts. What is a simple conflict? A graphical visualization of both sides of conflicts would help. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Google Summer of Code Projects
Hi Tim, Graham submitted the application yesterday. It's almost same as thishttp://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2010/Organisation_Application. The portal is open for editing till March 12'10 . We are still looking for more project ideas, and volunteers for mentoring, if you have some ideas or anybody from OSM community has them, please feel free to edit GSoC Project Ideas 2010http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2010page. Thanks, Rajan On Tue, Mar 9, 2010 at 6:42 PM, Tim Waters chippy2...@gmail.com wrote: Just a little bump to us that applications are open for organisations to apply, and we have 3 days left. http://google-opensource.blogspot.com/2010/03/google-summer-of-code-applications-now.html Tim On 28 February 2010 19:05, Graham Jones grahamjones...@googlemail.com wrote: Hi There, It will soon be time for OpenStreetMap to apply to join the 2010 Google Summer of Code Programme. This gives students the opportunity to work on open source projects during the summer, for which they receive some payment by Google. It costs us nothing more than providing a Mentor to guide the student. It would be really useful if we could put together a list of potential student projects to get potential applicants thinking. The projects need to be fairly well defined to make it easy to judge 'success', so it is good to have specific targets. From recent discussions on these lists I have identified the following possibilities so far: Develop a stand alone 'Newbie'/'Introductory'/'Lite' Editor - the priority is ease of use rather than functionality. Help with the development of Potlatch 2 (maybe to include the 'lite' editor functionality) - we would need to help the applicants identify specific targets. Develop a simple 'mapping tool' for mobile phones to easily collect GPX traces, geotagged images and geotagged audio clips. Ideally it should be capable of running on both Android, J2ME and Iphones, so you can have the same simple application no matter what sort of phone you use. Improve the usability of a simple mobile phone map editing application (such as vespucci for android). Incorporation of OSM data and traffic data. I am sure there are other things that I am not familiar with too - would it be useful for someone to do some work on tools to process OSM data in some way, or are there any tasks on the OSM server itself that could be turned into projects? Please will you give some thought to other possibilities and either add them to the GSoC 2010 Wiki Page (http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2010) or reply by email if you prefer. Thanks Graham. -- Graham Jones Hartlepool, UK email: grahamjones...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Rajan Vaish ASE at Accenture Technology Labs (RD) http://LinkedIn.com/in/RajanVaish ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - a renderd alternative
Stefan, Stefan de Konink wrote: The same host thing is not what my future is. The idea of multiple render services that can be balanced by the webserver is. But since it is now also unknown if one could actually connect to a remote tile service, I would bias for TCP. I agree that distributed rendering is something that must be supported. There are several ways to do it; either run a classic load balancer setup with some intelligence so that it requests odd tiles from one server and even tiles from another etc., or build a mesh of queue managers that are aware of each other, or have one master queue manager (a.k.a. single point of failure) distributing requests across a range of render servers. If you were to attempt the latter, I would recommend a messaging deamon that takes UDP requests and transports them to the other side using TCP. That would allow you to have a steady TCP connection and monitor it properly. For localhost use, we decided against TCP because creating a new connection everytime you need one is too expensive, and re-using the existing one causes too much trouble. In theory, Tirex could also be expanded to use multiple messaging schemes, just as it uses UDP and Unix domain sockets (for backward compatibility) now. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Edit in JOSM link
josm://openstreetmap.org/edit?lat=xlon=x http://openstreetmap.org/edit?lat=xlon=x This could also launch josm if it's not started already. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - a renderd alternative
Op 09-03-10 17:19, Frederik Ramm schreef: I agree that distributed rendering is something that must be supported. There are several ways to do it; either run a classic load balancer setup with some intelligence so that it requests odd tiles from one server and even tiles from another etc., or build a mesh of queue managers that are aware of each other, or have one master queue manager (a.k.a. single point of failure) distributing requests across a range of render servers. I currently have a webserver that does this for me. If you were to attempt the latter, I would recommend a messaging deamon that takes UDP requests and transports them to the other side using TCP. That would allow you to have a steady TCP connection and monitor it properly. For localhost use, we decided against TCP because creating a new connection everytime you need one is too expensive, and re-using the existing one causes too much trouble. If I would go into this direction I would go by multicast such as mDNS, and make render clients bid for rendering the requests. More flexible approach. And gives guarantees someone picks it up. In theory, Tirex could also be expanded to use multiple messaging schemes, just as it uses UDP and Unix domain sockets (for backward compatibility) now. I already like it that it is decoupled from the webserver itself. The only thing that has to be taken into account with an 'cgi' approach is the fork cost. But personally... I think with a small script that only shoots in the coordinates in a packet, that is good enough for anyone that doesn't want to write 25 lines of C. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Painting (was: how does the transition to tested work ?)
Dirk Stöcker wrote: A class to display a subset of the database in an own widget would be very helpful! There are multiple places in JOSM were we could use that. With lots of reworking done regarding data storage maybe it is possible to do that now. And best would be if selection does also work for this. Maybe a rework of the painting code could make it faster, as well. Currently for each rubber-band line a full repaint of the entire map is done. There is no caching, it just draws each object of each layer for every mouse move event. Consequently the drawing is quite slow if you are in a crowded area. However this goes away if you zoom in enough. Ironically we do unnecessary double buffering: It does not make a difference if you remove that offscreen buffer code in MapView.paint, except it is faster. (Apparently Swing does it's own double buffering unless you turn it off with setDoubleBuffered(false). This is on Linux/gnome, might be different for Windows and Mac.) I think we should cache all static data (osm objects, gpx layers, photo layer, ...) in a static cache that has to be marked as dirty if a repaint is needed. (E.g. when an object was deleted or layer visibility was toggled) Then the rest can be drawn on top like it is done now. Repainting is especially annoying when zooming and panning in a large dataset. For zooming there is not much we can do about it, but for panning it might be possible to reuse parts of the buffer by translating it accordingly. __ Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Painting
On Tue, 9 Mar 2010, Sebastian Klein wrote: I think we should cache all static data (osm objects, gpx layers, photo layer, ...) in a static cache that has to be marked as dirty if a repaint is needed. (E.g. when an object was deleted or layer visibility was toggled) Then the rest can be drawn on top like it is done now. Repainting is especially annoying when zooming and panning in a large dataset. For zooming there is not much we can do about it, but for panning it might be possible to reuse parts of the buffer by translating it accordingly. There was already someone trying to do as you suggest approx 1.4 years ago, but he had not the endurance to get it finished. The problem was that the design did not really have an easy way for dirty marking and thus the results to often got out of sync. But probably it is much easier than it was a year ago. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] OPEN STREET MAP - TRAFFIC INFORMATION
On Tue, 2010-03-09 at 11:03 +0100, Diego Castronuovo wrote: Hi Peter, have you started to work to this project? I think I will start to design something next month... Hey Diego, yes I have started a couple of months ago. On one hand I'm still trying to find the right approach to such a complex topic, on the other hand I tested some other open source projects and looked if they would be suited for such a complex application (e.g. pgrouting, Asterisk, osmosis, OSM Ruby gems and some other gems like the spatial adapter gem, OpenLayers,...). Furthermore import issues are already existing standards in the field of traffic information, like Datex2, TPEG, TMC. Of course I would prefer if I could implement all of them, at the moment TPEG seems to me as the most promising. Cause it contains elements for public transport as well (which is not the purpose of Datex2 and TMC). But back to the basic approach, I'm focusing on ontology driven architecture, which seems to me like a promising approach. But to be honest, I used not to work with ontology's in software development, so this topic is quite new to me. How did you think of starting with such a topic, do you have already a very fixed concept and what are you main goals? Are you interested in doing some parts, or most of it together? I would love to. I'm going update the GSoC Idea page soon, hope that makes my goals and the basic concept clear. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OPEN STREET MAP - TRAFFIC INFORMATION
Peter, Please do update the GSoC ideas page - the deadline for organisation applications is the end of this week, after which Google will be looking through all of the Organisations' ideas pages to choose which ones to accept (and possibly decide how many student places to give them) - the more (and more detailed) ideas the better to help that. Thanks Graham. On 9 March 2010 18:01, peter petervo...@gmail.com wrote: On Tue, 2010-03-09 at 11:03 +0100, Diego Castronuovo wrote: Hi Peter, have you started to work to this project? I think I will start to design something next month... Hey Diego, yes I have started a couple of months ago. On one hand I'm still trying to find the right approach to such a complex topic, on the other hand I tested some other open source projects and looked if they would be suited for such a complex application (e.g. pgrouting, Asterisk, osmosis, OSM Ruby gems and some other gems like the spatial adapter gem, OpenLayers,...). Furthermore import issues are already existing standards in the field of traffic information, like Datex2, TPEG, TMC. Of course I would prefer if I could implement all of them, at the moment TPEG seems to me as the most promising. Cause it contains elements for public transport as well (which is not the purpose of Datex2 and TMC). But back to the basic approach, I'm focusing on ontology driven architecture, which seems to me like a promising approach. But to be honest, I used not to work with ontology's in software development, so this topic is quite new to me. How did you think of starting with such a topic, do you have already a very fixed concept and what are you main goals? Are you interested in doing some parts, or most of it together? I would love to. I'm going update the GSoC Idea page soon, hope that makes my goals and the basic concept clear. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Dr. Graham Jones Hartlepool, UK email: grahamjones...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Painting (was: how does the transition to tested work ?)
Maybe a rework of the painting code could make it faster, as well. Currently for each rubber-band line a full repaint of the entire map is done. There is no caching, it just draws each object of each layer for every mouse move event. ... I think we should cache all static data (osm objects, gpx layers, photo layer, ...) in a static cache that has to be marked as dirty if a repaint is needed. (E.g. when an object was deleted or layer visibility was toggled) I think mappaint consume most of the painting time so it should be enough to cache OsmDataLayer. It would be also nice to have code for painting normal and selected/highligted primitives separated so there can be buffer of static data which will be repainted only when dataset is changed. Repainting is especially annoying when zooming and panning in a large dataset. For zooming there is not much we can do about it, but for panning it might be possible to reuse parts of the buffer by translating it accordingly. One of the reason why painting appears slow is the fact that it's done in EDT thread. I think there should be special thread for painting. EDT will only send request to repaint and copy offscreen buffer to screen when it's ready. Painting thread will wait for repaint requests. When request arrives it will start painting immediately. If another request arrives during painting, it will wait. If there are multiple repaint request after painting is finished, only the last one will be processed. __ Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugins not working with 3094 and Linux ?
Hi, Do we have to modify the ant files and recompile all plugins for Java6 ? the public build.xml for the JOSM core still compiles for Java 5 (both source and target). So do the build.xml for the plugins. Most of them have the property property name=ant.build.javac.target value=1.5 / set (cadastre_fr too). Latest is still compiled for Java 1.5, as far as I can tell- the major version of the class files is 49. I don't know when the JOSM core is going to be compiled for Java 6. On this list I have been reading about plans to switch to Java 6 one or two weeks ago. Perhaps it has been postponed by another month or two in the meantime. Plugins should probably wait to compile for Java 6 until the JOSM core is available for Java 6. Regards Karl Am 09.03.2010 12:39, schrieb Pieren: Hi, I received already two complains about 3094 and the cadastre-fr plugin not working on Linux (ubuntu or Debian Etch) with a java6 env. Exception is : java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) Do we have to modify the ant files and recompile all plugins for Java6 ? Strange is that it works fine on Windows. Pieren ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Tirex - a renderd alternative
Hi, Stefan de Konink wrote: I agree that distributed rendering is something that must be supported. There are several ways to do it; either run a classic load balancer setup with some intelligence so that it requests odd tiles from one server and even tiles from another etc., or build a mesh of queue managers that are aware of each other, or have one master queue manager (a.k.a. single point of failure) distributing requests across a range of render servers. I currently have a webserver that does this for me. A web server is sufficient for simple applications but if you want to pre-render a million tiles without impeding on live viewing performance then a more controlled approach is probably required. If I would go into this direction I would go by multicast such as mDNS, and make render clients bid for rendering the requests. More flexible approach. And gives guarantees someone picks it up. Sounds interesting. I don't understand enough about that but if anyone wants to try... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] deleted vs. visible
Have a look at #4687 (unsolvable conflict with nodes). It's about node that is not visible on server and has also been removed in josm. That produce two conflicts (one for deleted, other one for visible). Resolution of conflicts ends with an exception. I think correct way to fix this is show only deleted state (so in this case the node will have no conflict). On Fri, Mar 5, 2010 at 11:04 PM, Matthias Julius li...@julius-net.net wrote: I need to brung up this subject again. I still can not wrap my head around why we need to distinguish between deleted and visible state for primitives and bother the user with it. AFAICT, isDeleted()==true is equivalent to isVisible()==false isModified()==true. I believe there is currently no way to have primitives with either isDeleted()==true isModified()==false or isVisible()==false isModified()==true. Therefore, I think the two flags can be consolidated. IMO, it is enough to have the DELETED flag and to distinguish between deleted locally and deleted on server the MODIFIED flag should be enough. This would simplify both merging and conflict handling. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Tirex - a renderd alternative
2010/3/8 Frederik Ramm frede...@remote.org: a few days ago I committed a first working version of Tirex to our svn (under applications/utils). Tirex is basically an alternative for renderd, it does the same things, just differently. Nice. It would be cool if it supported pluggable elaborate rendering flows like the one used in http://wiki.openstreetmap.org/wiki/TopOSM/Details. Cheers Colin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - a renderd alternative
Op 09-03-10 21:28, Frederik Ramm schreef: I agree that distributed rendering is something that must be supported. There are several ways to do it; either run a classic load balancer setup with some intelligence so that it requests odd tiles from one server and even tiles from another etc., or build a mesh of queue managers that are aware of each other, or have one master queue manager (a.k.a. single point of failure) distributing requests across a range of render servers. I currently have a webserver that does this for me. A web server is sufficient for simple applications but if you want to pre-render a million tiles without impeding on live viewing performance then a more controlled approach is probably required. Sure but in that case I would go for the 'nuke a zillion udp packets to somewhere'. If I would go into this direction I would go by multicast such as mDNS, and make render clients bid for rendering the requests. More flexible approach. And gives guarantees someone picks it up. Sounds interesting. I don't understand enough about that but if anyone wants to try... Basically it works like a negotiation strategy. But we can discuss it offline. Its trivial te implement it or to copy it from one of my other projects. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Openstreetmap and the AMD 48 core contest
thanks kevin anyone want to apply for this? On Mar 8, 2010, at 11:52 PM, Kevin's Hobbies - www.scale18.com wrote: Hi Steve, I saw this in a recent slashdot submission page and I thought that you guys might be interested. What Would You Do With 48 Cores? The AMD Server team is kicking March off with a new contest. We are seeking your best essays, videos, or blog posts documenting how you might use 48 cores. One winner will be selected and awarded with: * Four new AMD Opteron™ processors Model 6174, 12-core (2.2 GHz) * TYAN S8812 motherboard: the motherboard is a Tyan S8812 that features 4 processor sockets with the capacity for you to install up to 8 DIMMs per socket * one copy of Windows Server® 2008 Approximate retail value of all prizes is $8,189 USD. http://blogs.amd.com/work/2010/03/03/48-cores-contest/ Cheers, Kevin Pickell http://code.google.com/p/gpsturbo/ Yours c. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Openstreetmap and the AMD 48 core contest
I'll apply for this... Anyone have any video of mapping activity or mapping party? If there's a few minutes-worth of good footage I'll mix together a video, otherwise a blog or essay will have to do. On Tue, Mar 9, 2010 at 9:16 PM, SteveC st...@asklater.com wrote: thanks kevin anyone want to apply for this? On Mar 8, 2010, at 11:52 PM, Kevin's Hobbies - www.scale18.com wrote: Hi Steve, I saw this in a recent slashdot submission page and I thought that you guys might be interested. What Would You Do With 48 Cores? The AMD Server team is kicking March off with a new contest. We are seeking your best essays, videos, or blog posts documenting how you might use 48 cores. One winner will be selected and awarded with: * Four new AMD Opteron™ processors Model 6174, 12-core (2.2 GHz) * TYAN S8812 motherboard: the motherboard is a Tyan S8812 that features 4 processor sockets with the capacity for you to install up to 8 DIMMs per socket * one copy of Windows Server® 2008 Approximate retail value of all prizes is $8,189 USD. http://blogs.amd.com/work/2010/03/03/48-cores-contest/ Cheers, Kevin Pickell http://code.google.com/p/gpsturbo/ Yours c. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
On Fri, Mar 5, 2010 at 2:12 AM, Ian Dees ian.d...@gmail.com wrote: On Thu, Mar 4, 2010 at 9:05 AM, Andy Allan gravityst...@gmail.com wrote: On Thu, Mar 4, 2010 at 3:52 AM, Blars Blarson openstreetmap-...@scd.debian.net wrote: This is just to let you all know TRAPI development has been suspended and may never resume. That's a great shame. Would it be possible for you to commit to svn the work-in-progress, in case anyone wants to finish off your hard work at some point in the future? Also, forgive me if this shows my ignorance of TRAPI, but do you think it would be feasible to rework the import to use osmosis for the replication diff fetching? I was thinking that a custom output plugin could be created to write out the osm data in whichever format was needed for the rest of the TRAPI update process. I started working on a streaming XML output plugin for Osmosis. I was intending to take advantage of PuSH/PubSubHub messaging and maybe even XMPP (so that you get a 1-min delayed IM when someone changes something in your bbox). Anyway, TRAPI could use this same plugin to apply updates to their database. I've also spent a fair bit of time thinking about this type of thing. When I first started work on the replication diffs I had in mind a server-side daemon (using Osmosis internally) that would push changes to all connected clients. It would allow a client to connect, specify which replication number it was up to, receive all updates in a single stream, then continue to receive live changes as they occurred. Several issues preventing this are: 1. Writing it. I don't have much time to do it therefore I went with the simplest approach that would work at the time. 2. Cacheability. A push approach is non-cacheable and therefore would increase the amount of bandwidth required. I suspect diff updates are small compared with planet downloads though so perhaps this is a non-issue. 3. TCP port availability. The UCL servers only have limited ports accessible to the outside world. This would probably have to sit behind an Apache web server and therefore be HTTP based. 4. Additional administration overhead. For the last few months I have spent literally zero time looking after the replication updates. I can't remember the last time I logged into the services server. Unless somebody else is stepping in and helping out without me being aware, the current mechanism is very reliable. Occasional db or network errors occur causing the cron-based replication jobs to fail, but they recover and pick up where the left off next time things become available again. In summary, the current approach isn't perfect and could certainly be improved. But unless somebody has the time and inclination to write it themselves, go to the trouble of incorporating it into the existing infrastructure, resolve the inevitable issues that arise, and be prepared to administer it on an ongoing basis, it probably won't change any time soon. But I would really like to see it happen :-) Brett ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] how does the transition to tested work ?
Ævar Arnfjörð Bjarmason wrote: I just tried and I can't reproduce this or the issue with the number of objects to be uploaded drifting from what really needs to be uploaded. Now if I upload a per-object upload and it fails partway the objects that were uploaded up until that point will be counted as uploaded and won't be re-uploaded. But like I said I don't know if this issue in particular was what was causing some of the duplicates I was seeing initially. Thanks for clearing this up. If you find other pitfalls, or run across data destroying bugs, please let us know! (Power users like you and Skyper seem to have a much higher probability of running into these. :) ) __ Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Function to select or download a sequence of ways?
Hi Marko To the best of my knowlege there is no such function yet ... As a further development, it could be useful to create a selective download function (follow this way until reaching a branch or a given bounding box). ... except for this function which sounds like what the waydownloader plugin provides. Selection is a core thing. You can use it from plugins in three ways. (1) you can influence the current selection. See setSelected() on DataSet. Invoke it on the current data layer (Main.main.getEditLayer()) (2) you can get the current selection. See getSelected() on DataSet. Invoke it on the current data layer (Main.main.getEditLayer()) (3) you can listen to the current selection. See org.openstreetmap.josm.data.osm.event.SelectionEventManager Regards Karl Am 09.03.2010 10:07, schrieb Marko Mäkelä: Before I start reinventing the wheel in JOSM, I would like to know if there is a function or plugin that allows to select a non-branching sequence of ways. It would be nice if the selection function could optionally be restricted to the current selection, just like the search dialog, and if some predicates could be assigned to the ways, say, highway=tertiary or natural=coastline, so that any branches where the predicate does not hold would be ignored. With such a selection function, it would be easy to select the coastline of an area within a natural=coastline extract of the planet extract, or to select a section of highway or railway for defining a route relation, for instance. Last, some questions to help getting me started, in case this does not exist yet. Is the selection a core thing, or can this be done in a plugin? Where should I start looking first? As a further development, it could be useful to create a selective download function (follow this way until reaching a branch or a given bounding box). Best regards, Marko ___ 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] Painting
Jiri Klement wrote: One of the reason why painting appears slow is the fact that it's done in EDT thread. I think there should be special thread for painting. Disagreed (with both sentences). EDT will only send request to repaint and copy offscreen buffer to screen when it's ready. Painting thread will wait for repaint requests. When request arrives it will start painting immediately. If another request arrives during painting, it will wait. If there are multiple repaint request after painting is finished, only the last one will be processed. This is exactly what RepaintManager in Java does for you. User events (mouse gestures, ...) and posted tasks are processed and the repaint requests they caused are buffered and a repaint request is posted at the end of the event queue. Once the queue drains, the repaint happens, only once. If you think of coleascing paints across more user gestures (like continuous dragging), you'll face two problems: 1) the trade-off between UI responsivity and the amount of coalesced events. Too short delay before painting and you paint on every event anyway. Too long delay and the UI will feel slow most of the time. 2) Loss of feedback in the cases where the painting already takes considerable amount of time. Separate thread won't help you neither on multicores, as you'll keep the problem serialized. Everything else but painting is fast enough, so you'll have AWT thread idle happily waiting for next event while the painting thread will fully load one core. Well, there will be the benefit of having the rest of the UI responsive, but we're not here to solve multisecond painting of zoom-to-fit of large datasets this time, are we? As for the initial comment regarding full repaint just to do rubber-band: There's no problem with full repaint as long as you do it fast enough. And this is doable. Proved. Moreover, I fear the increased code complexity necessary for partial, maybe filtered, repaints may slow down the general painting so the net result will be worse. For the record, I've tried current JOSM and must say that the rendering speed improved a lot. What might help, IMO, is to disable painting plain points over given zoom level. JOSM already paints large datasets when zoomed in and slight simplification, when zoomed out can only improve the situation. (You don't need to see individual nodes when looking at half the Germany, do you?) Regards, Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugins not working with 3094 and Linux ?
Karl Guggisberg wrote: I don't know when the JOSM core is going to be compiled for Java 6. On this list I have been reading about plans to switch to Java 6 one or two weeks ago. Perhaps it has been postponed by another month or two in the meantime. Plugins should probably wait to compile for Java 6 until the JOSM core is available for Java 6. I think it is quite clear: The final decision on the Java 6 switch will be made after the stabilization bugfixing phase. (Which has started early January and apparently isn't over.) __ Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Painting
Sebastian Klein wrote: I was wondering: Is it save to paint to the Graphics of some component from a random thread at a random time? No, it is not safe, but that's not what you'd be doing. The painting will proceed into a BufferedImage, which will then be painted in the event thread using the component's Graphics. -- Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
