[OSM-dev] GSoC Introduction
Hello everyone, my name is André Pereira and I'm a Masters student at Universidade do Minho in Portugal. I'm currently specializing in two areas: Computer Graphics; Language Processing and Compilers. I've also studied Parallel Computing and Optimization. The language in which I'm most comfortable in is Java, and since I'm specializing in Computer Graphics, I have experience in OpenGL and Computer Vision, which are required for some of the projects. I've looked at your project proposals and there are a few that I find interesting: *a) Recording and Playback of Camera Movement in OSM2World* Do you have a format in the works or is it up to the student to develop it? *b) A WebGL frontend for OSM2World* What is the format of the 3D data tiles? Do you want full 3D camera movement? *c) JOSM Plugin to work with Mapillary imagesd) Image filters for Raster layers in JOSM* Can you provide more details on this project? Can you please tell me which of these projects are top priority, so that I can focus in one of them? Looking forward to a reply! Best regards, André Pereira ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC: OpenGL view for JOSM
Hello, This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses MapCSS to render a style in the view. That way, many existing styles can be used with the new interface. This will be the most part of the work on this project. As library I would currently prefer JOGL, since I already have experience with it and it contains some additional features we would need (like text rendering support and the ability to be added as swing panel). Current status: - Currently, each layer draws it self to the Java Graphics. Most layers are not really extensible (like the GPX-Track feature), which makes it hard to modify them using plugins (like adding non-standard accuracy info to GPX and drawing the accuracy area instead of the line). - Layers are drawn the way they are ordered in the side view. - There are basically two types of layers: Background layers (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java, OsmDataLayer.java, ...) Implementation details/ideas (so far): - JOSM create a list of Drawer objects for each layer. - I would like to use a 2D plane (which can then be offsetted using shaders) to be the background for all of the map. There is only one background pane with the textures of background layers added to it. I will have to look more into shaders (like supporting an unlimited number of textures on a single area) but I hope this is possible. -- Fallback: Just render the images as rectangle, one over the other, using opacity settings and disabling the depth buffer (the way it is done currently). Cache using VBOs. This is not as modern as shaders would be, but it is simple. - Layers make heavy use of VBOs. I would like to provide a nice interface to draw and cache VBO structures. This will also speed up drawing of the map a lot, since the map does not change. Thinks it should do include: -- Draw a point at the given lat/lon -- Draw a line of width x with given (lat/lon/width) point pairs and color, closed or open. -- Draw a filled area (without contour) -- Add text at a given position. -- MapCSS properties this basically supports: width, color (rgba), dashes, linecap, linejoin, fill-color (rgba), font-size, text-color, text-offset, text. -- What we won't support: z-index (but we could order the elements before drawing), casing, extrude, icons, text-position. - Each VBO is tied to map objects that it depends on. That way, it only needs to be updated if those objects change. Doing this is done by the renderer (which also has knowledge of all MapCSS styles). -- The MapCSS renderer needs to be adjusted to keep track of object changes and re-create a VBO as soon as it's rules change. Implementation schedule (12 weeks until pencils down) 2 Weeks: Getting to know JOSM and adding the OpenGL view to the core (and an interface to use it). 2 Weeks: Adding the OpenGL interfaces we need (like computing the OpenGL-Coordinates for a point on earth and the
[OSM-dev] New Applicant
Hello. I'm called Harvey Sama, a final year Student at the Faculty of Engineering - University of Buea. I am Interested in working on the projects Image filters for Raster layers in JOSM or JOSM support for WMTS images. I code in Java, JavaFX and Java EE. I would like to get information about how to go about downloading the source code and setting up development environment. Best regards. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Invisible way
Thanks Dirk and Jochen (again). We fixed the incomplete ways bug in our output so the display bug no longer appears. This thread has given me some more clarity about the file format definition. I will try and capture that in the JXML wiki page also. (Oh and yes the extraneous tags like `foo` and `lastUser` would never make it into any file we'd ever release - like I said these are still fairly early experiments.) On Mon, Mar 9, 2015 at 9:30 AM, Jochen Topf joc...@remote.org wrote: On Mo, Mär 09, 2015 at 09:10:55 -0600, Martijn van Exel wrote: If the file is really incomplete, I don't think JOSM should accept it - or at least not without some kind of warning. The current behavior is ambiguous: it loads the file without any warning or error, and merges with another layer just fine, but it does not display the file (because obviously it does not have enough information.) Or is this because the JOSM file format is not well enough defined? There is nothing on the wiki suggesting a JXML file should contain all existing nodes in a way, or what happens if it doesn't. Should I write a clarification? JOSM does report those problems, but on STDOUT, maybe you didn't see it. JOSM being a GUI program should probably report it through the GUI though... And it should be obvious that you have to have all nodes needed for a way in the data if you want it to show up properly. Thats just standard OSM format, nothing special about JOSM that way. Of course it would be nice if JOSM documented what it does if thats not the case. Another issue I just noticed in the changes.osm file: You timestamps are probably not conforming. Please don't use microseconds and always use timezone Z. Some programs will, no doubt, parse your file correctly, but others will not. And I hope all those tags are just for experimenting. Tags lastUser and foo make no sense and tag source these days belongs on the changeset, not on the objects. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 -- Martijn van Exel skype: mvexel ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[OSM-dev] vacuum running amok - and me too ;)
Hi, tried to get help on the postgresql-general forum but they didn't help me yet. (http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-too-td5840299.html) *Vacuum planet_osm_ways* is using very, very much memory vacuuming the GIN-Index planet_osm_ways_nodes. Running on a 24GB-System with now 50GB Swap i had to kill the Vacuum after using about 68 GB Virt memory ( 80% total) because of thrashing. the postgresql-config-params are very conservative, because i reduced them to minimize mem usage: http://gis.19327.n5.nabble.com/file/n5836373/pidstat.png A graph on memory usage during vaccuuming until i had to reboot my system. left scale virt mem in MB. Any hints? Feeling helpless. Regards walter - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0.2[/url] -- View this message in context: http://gis.19327.n5.nabble.com/vacuum-running-amok-and-me-too-tp5836373.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Invisible way
On Mon, 9 Mar 2015, Martijn van Exel wrote: If the file is really incomplete, I don't think JOSM should accept it - or at least not without some kind of warning. The current behavior is ambiguous: it loads the file without any warning or error, and merges with another layer just fine, but it does not display the file (because obviously it does not have enough information.) Or is this because the JOSM file format is not well enough defined? There is nothing on the wiki suggesting a JXML file should contain all existing nodes in a way, or what happens if it doesn't. Should I write a clarification? JOSM can also handle incomplete data sets, where referenced objects are missing. For relations this is obvious. For other types not so much. Anyway that's a feature. :-) But usually it is not recommended to use that feature unless you really know what you are doing. That's why most suggested XAPI/Overpass/API requests include the referenced objects to reduce trouble, but it works without. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Invisible way
On Mo, Mär 09, 2015 at 09:10:55 -0600, Martijn van Exel wrote: If the file is really incomplete, I don't think JOSM should accept it - or at least not without some kind of warning. The current behavior is ambiguous: it loads the file without any warning or error, and merges with another layer just fine, but it does not display the file (because obviously it does not have enough information.) Or is this because the JOSM file format is not well enough defined? There is nothing on the wiki suggesting a JXML file should contain all existing nodes in a way, or what happens if it doesn't. Should I write a clarification? JOSM does report those problems, but on STDOUT, maybe you didn't see it. JOSM being a GUI program should probably report it through the GUI though... And it should be obvious that you have to have all nodes needed for a way in the data if you want it to show up properly. Thats just standard OSM format, nothing special about JOSM that way. Of course it would be nice if JOSM documented what it does if thats not the case. Another issue I just noticed in the changes.osm file: You timestamps are probably not conforming. Please don't use microseconds and always use timezone Z. Some programs will, no doubt, parse your file correctly, but others will not. And I hope all those tags are just for experimenting. Tags lastUser and foo make no sense and tag source these days belongs on the changeset, not on the objects. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Invisible way
Hey Tod, Vincent and Jochen, Thanks for looking at this also. If the file is really incomplete, I don't think JOSM should accept it - or at least not without some kind of warning. The current behavior is ambiguous: it loads the file without any warning or error, and merges with another layer just fine, but it does not display the file (because obviously it does not have enough information.) Or is this because the JOSM file format is not well enough defined? There is nothing on the wiki suggesting a JXML file should contain all existing nodes in a way, or what happens if it doesn't. Should I write a clarification? 'GraphEnhancer' is our own tool-in-development so consider the bug reported. We will investigate further on our end. On Mon, Mar 9, 2015 at 1:37 AM, Vincent Privat vincent.pri...@gmail.com wrote: This is rather a bug of the software that produces the .osm file (GraphEnhancer 1.0.0), not JOSM. Half the nodes are missing in your file. Please report the bug to them. 2015-03-09 8:25 GMT+01:00 Jochen Topf joc...@remote.org: On So, Mär 08, 2015 at 11:11:15 -0600, Martijn van Exel wrote: I just had a weird experience with a JOSM XML file where some ways are present but not visible on the map. I described the issue in some detail in my diary: https://www.openstreetmap.org/user/mvexel/diary/34521 Before I open a ticket I just want to make sure I am not missing something? I see two problems: 1. Not sure how you generated that base.osm.pbf, but it contains a way without any attributes. If I convert this with osmium to XML I get: way id=813/ with Osmosis I get: way id=813 version=0 timestamp=1970-01-01T00:00:00Z/ 2. My JOSM reports these: INFO: Way -1 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -72 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -65 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -66 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -67 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -68 with 5 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -20 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -22 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -21 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -24 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -36 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -40 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -37 with 4 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -43 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -44 with 7 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -41 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -51 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -50 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -54 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -53 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -64 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -63 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -62 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. I haven't looked farther than this. Not sure any of this explains your problems, but fix them first and we'll see then. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev -- Martijn van Exel skype: mvexel ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[OSM-dev] GraphHopper route planner 0.4 released
Hi, [cross posting to routing and dev] we've released a new version 0.4 of the fast route planner GraphHopper today: https://karussell.wordpress.com/2015/03/09/releasing-graphhopper-0-4-and-the-graphhopper-directions-api/ Kind Regards, Peter from the GraphHopper Team ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New Applicant
Hi Harvey, There are some details about project itself, and link to JOSM developers howto. 2015-03-09 16:26 GMT+05:00 Harvey Sama princeme.s...@gmail.com: Hello. I’m called Harvey Sama, a final year Student at the Faculty of Engineering - University of Buea. I am Interested in working on the projects *Image filters for Raster layers in JOSM *or JOSM support for WMTS images. I code in Java, JavaFX and Java EE. I would like to get information about how to go about downloading the source code and setting up development environment. Best regards. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Thank you for your time. Best regards. Dmitry. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Partial Website + API outage
Hi All, OpenStreetMap is currently offline due to a network problem at the data centre which hosts us. Status updates here: https://twitter.com/OSM_Tech/ Alternative: #osm-dev on http://irc.openstreetmap.org/ We are trying to get everything back up ASAP, but currently do not yet have an ETA. Kind regards, Grant Part of the OSM sysadmin team ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[josm-dev] Fwd: GSoC: OpenGL view for JOSM
Hi, I'm also posting this on the JOSM-List in hope to get feedback on the technical parts here. Regards, Michael Weitergeleitete Nachricht Betreff: [OSM-dev] GSoC: OpenGL view for JOSM Datum: Mon, 09 Mar 2015 13:58:41 +0100 Von: Michael Zangl openstreet...@michael.fam-zangl.net An: d...@openstreetmap.org Hello, This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses MapCSS to render a style in the view. That way, many existing styles can be used with the new interface. This will be the most part of the work on this project. As library I would currently prefer JOGL, since I already have experience with it and it contains some additional features we would need (like text rendering support and the ability to be added as swing panel). Current status: - Currently, each layer draws it self to the Java Graphics. Most layers are not really extensible (like the GPX-Track feature), which makes it hard to modify them using plugins (like adding non-standard accuracy info to GPX and drawing the accuracy area instead of the line). - Layers are drawn the way they are ordered in the side view. - There are basically two types of layers: Background layers (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java, OsmDataLayer.java, ...) Implementation details/ideas (so far): - JOSM create a list of Drawer objects for each layer. - I would like to use a 2D plane (which can then be offsetted using shaders) to be the background for all of the map. There is only one background pane with the textures of background layers added to it. I will have to look more into shaders (like supporting an unlimited number of textures on a single area) but I hope this is possible. -- Fallback: Just render the images as rectangle, one over the other, using opacity settings and disabling the depth buffer (the way it is done currently). Cache using VBOs. This is not as modern as shaders would be, but it is simple. - Layers make heavy use of VBOs. I would like to provide a nice interface to draw and cache VBO structures. This will also speed up drawing of the map a lot, since the map does not change. Thinks it should do include: -- Draw a point at the given lat/lon -- Draw a line of width x with given (lat/lon/width) point pairs and color, closed or open. -- Draw a filled area (without contour) -- Add text at a given position. -- MapCSS properties this basically supports: width, color (rgba), dashes, linecap, linejoin, fill-color (rgba), font-size, text-color, text-offset, text. -- What we won't support: z-index (but we could order the elements before drawing), casing, extrude, icons, text-position. - Each VBO is tied to map objects that it depends on. That way, it only needs to be updated if those objects change. Doing this is done by the renderer (which also has knowledge of all MapCSS styles). -- The MapCSS renderer needs to be adjusted to keep track of object
Re: [OSM-dev] Greetings Openstreet Community : GSOC queries
Hey Ankit - On Thu, Mar 5, 2015 at 11:46 PM, Ankit Kumar ankit...@iitk.ac.in wrote: Kindly guide how do I start working for this project ? Expectations in Proposals ? I'm sure you've seen that actual time window for applications isn't open yet: http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2015#Application So to get a headstart, I encourage you to familiarize yourself with Overpass API, review all available documentation and develop ideas of what could be improved. Here are good starting points: - Overpass docs on the OSM wiki http://wiki.openstreetmap.org/wiki/Overpass_API - Very popular web interface to the Overpass API http://overpass-turbo.eu/ Please also reach out to tyr_asd - the possible mentor for this project: http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2015/Project_Ideas It will make sense to have some of discussions with your potential mentor out here on the list to the benefit of others who're thinking about the same problem. Cheers and much luck - Alex ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Partial Website + API outage
+1Should we buy a super-heros suit to @firefishy1? Pierre De : Clifford Snow cliff...@snowandsnow.us À : Richard Weait rich...@weait.com Cc : dev Openstreetmap dev@openstreetmap.org; annou...@openstreetmap.org; Talk Openstreetmap t...@openstreetmap.org Envoyé le : Lundi 9 mars 2015 17h10 Objet : Re: [OSM-talk] [OSM-dev] Partial Website + API outage +1 On Mar 9, 2015 2:39 PM, Richard Weait rich...@weait.com wrote: On Mon, Mar 9, 2015 at 4:26 PM, Grant Slater openstreet...@firefishy.com wrote: All servers are now back to normal. Thank you, Admin Super Heroes. :-) ___ talk mailing list t...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list t...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Partial Website + API outage
On 9 Mar 2015 17:38, Grant Slater openstreet...@firefishy.com wrote: Hi All, OpenStreetMap is currently offline due to a network problem at the data centre which hosts us. Status updates here: https://twitter.com/OSM_Tech/ Alternative: #osm-dev on http://irc.openstreetmap.org/ We are trying to get everything back up ASAP, but currently do not yet have an ETA. All servers are now back to normal. Kind regards, Grant ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC Introduction
Hello André, welcome and thank you for considering OpenStreetMap as a mentoring organization. I'm going to reply only to those questions I'm qualified to answer, see below. I hope someone from the JOSM community will take the time to respond to your other questions. On 09.03.2015 13:36, Andre Pereira wrote: *a) Recording and Playback of Camera Movement in OSM2World* Do you have a format in the works or is it up to the student to develop it? I assume you refer to the file format for the camera path. Determining which format(s) is/are suitable for the task is part of the project. It is likely that formats like gpx (which is used a lot in the OSM ecosystem) or kml might fit the bill, though. If those formats are insufficient for the intended functionality, a custom format may also be created. *b) A WebGL frontend for OSM2World* What is the format of the 3D data tiles? Do you want full 3D camera movement? The 3D data tiles are going to be in a custom binary format, which is going to be developed hand in hand with the WebGL client. The tiles will contain mostly pre-calculated 3D models from a server running the actual OSM2World software. The client's task is to load, cache, arrange, and render the 3D content as efficiently as possible. Part of the challenge lies in the rather large amount of data that needs to be transferred and visualized. Ideally, the WebGL client should allow full 3D camera movement, although I would still consider an otherwise working client with restricted movement a successful completion of the project. Can you please tell me which of these projects are top priority, so that I can focus in one of them? The final priority ranking is determined only after the student applications have arrived, by a vote of all project mentors. They will take not only the project into account, but also the skills and qualifications of the student(s) applying for a project. Among the projects I have offered to mentor, however, the WebGL frontend is clearly my main priority. Kind regards, Tobias Knerr ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Invisible way
On So, Mär 08, 2015 at 11:11:15 -0600, Martijn van Exel wrote: I just had a weird experience with a JOSM XML file where some ways are present but not visible on the map. I described the issue in some detail in my diary: https://www.openstreetmap.org/user/mvexel/diary/34521 Before I open a ticket I just want to make sure I am not missing something? I see two problems: 1. Not sure how you generated that base.osm.pbf, but it contains a way without any attributes. If I convert this with osmium to XML I get: way id=813/ with Osmosis I get: way id=813 version=0 timestamp=1970-01-01T00:00:00Z/ 2. My JOSM reports these: INFO: Way -1 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -72 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -65 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -66 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -67 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -68 with 5 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -20 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -22 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -21 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -24 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -36 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -40 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -37 with 4 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -43 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -44 with 7 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -41 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -51 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -50 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -54 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -53 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -64 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -63 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -62 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. I haven't looked farther than this. Not sure any of this explains your problems, but fix them first and we'll see then. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Invisible way
This is rather a bug of the software that produces the .osm file (GraphEnhancer 1.0.0), not JOSM. Half the nodes are missing in your file. Please report the bug to them. 2015-03-09 8:25 GMT+01:00 Jochen Topf joc...@remote.org: On So, Mär 08, 2015 at 11:11:15 -0600, Martijn van Exel wrote: I just had a weird experience with a JOSM XML file where some ways are present but not visible on the map. I described the issue in some detail in my diary: https://www.openstreetmap.org/user/mvexel/diary/34521 Before I open a ticket I just want to make sure I am not missing something? I see two problems: 1. Not sure how you generated that base.osm.pbf, but it contains a way without any attributes. If I convert this with osmium to XML I get: way id=813/ with Osmosis I get: way id=813 version=0 timestamp=1970-01-01T00:00:00Z/ 2. My JOSM reports these: INFO: Way -1 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -72 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -65 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -66 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -67 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -68 with 5 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -20 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -22 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -21 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -24 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -36 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -40 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -37 with 4 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -43 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -44 with 7 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -41 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -51 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -50 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -54 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -53 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -64 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -63 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. INFO: Way -62 with 2 nodes has incomplete nodes because at least one node was missing in the loaded data. I haven't looked farther than this. Not sure any of this explains your problems, but fix them first and we'll see then. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
