[osmosis-dev] Example code for PBF reading
Hi all, Are there any examples known to you that use the osmosis code in another project? I am specifically interested in using the PBF reading code. Or is there perhaps an easier way to add OSM PBF reading to my own (Java) project? Thx Martijn -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Example code for PBF reading
On Di, Mär 18, 2014 at 01:29:57 -0600, Martijn van Exel wrote: Are there any examples known to you that use the osmosis code in another project? I am specifically interested in using the PBF reading code. Or is there perhaps an easier way to add OSM PBF reading to my own (Java) project? There is some example PBF reading code in the OSM-binary repository https://github.com/scrosby/OSM-binary/blob/master/src.java/crosby/binary/test/ReadFileExample.java Also I think mkgmap (http://www.mkgmap.org.uk/) has its own PBF reading code based on OSM-binary. How good those implementations are, I don't know. Reading PBF files is not so simple, there are undocumented details that can trip you up. So using either of these might be more difficult than with Osmosis. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Example code for PBF reading
Osmosis just uses this library, right? I mean, it is a nicely packaged version of LGPLed OSM-binary: https://github.com/openstreetmap/osmosis/tree/master/osmosis-osm-binary Use it in maven via: dependency groupIdorg.openstreetmap.osmosis/groupId artifactIdosmosis-osm-binary/artifactId version0.43.1/version /dependency Regards, Peter. On Di, Mär 18, 2014 at 01:29:57 -0600, Martijn van Exel wrote: Are there any examples known to you that use the osmosis code in another project? I am specifically interested in using the PBF reading code. Or is there perhaps an easier way to add OSM PBF reading to my own (Java) project? There is some example PBF reading code in the OSM-binary repository https://github.com/scrosby/OSM-binary/blob/master/src.java/crosby/binary/test/ReadFileExample.java Also I think mkgmap (http://www.mkgmap.org.uk/) has its own PBF reading code based on OSM-binary. How good those implementations are, I don't know. Reading PBF files is not so simple, there are undocumented details that can trip you up. So using either of these might be more difficult than with Osmosis. Jochen -- GraphHopper.com - Fast Flexible Road Routing ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [OSM-dev] JOSM plugin public transport update (Google Summer of Code program)
Hello Markus, I'm sorry for the delayed answer. I'm currently preparing my talks on the FOSSGIS conference (German version of SotM) and this took much more time than expected. I thought about algorithm guessing connection type based on: - common tags on ways that contain selected nodes This is really smart. It would avoid most of the time bothering the user. - what type was previously selected (i.e. if a user had selected a type X in the past, then this selection will be assumed as more likely the next time) Also a good idea although I would see this rather as choosing which item to highlight. Some types would be predefined. There would be possibility to edit existing and add more. A connection type would have: - name - icon (not sure, requires testing whether it would be helpful) - set of data about tags that would identify ways that can be included - tags that must appear - tags that indicate this route type - tags that should not appear and indicate that it is not this type - tags that must not appear Additionally, features with certain tags could and should block routing even if they just cross the path without sharing a nnode. Think of a gate (barrier=gate or a military no-go area). I like this idea, but is it big enough to qualify as entire project? Maybe yes, especially after considering that things often are harder than expected and take far more time than it seemed at start. Yes, it is big enough. It is more more meritful to arrive at a useful piece of code first and then do one or more exciting features on top than a monolithic goal that could (and then, by Murphy's law, will) fail completely. In this project I see following parts - creation of ticket on JOSM bugtracker (I am not expecting this, but in case that JOSM developers reject the entire idea I would instead create plugin with this functionality). - collecting use cases (two nodes + what ways would be expected to be found by algorithm) - setting up development environment, with ability to build JOSM - interface (new position in tool menu, icon, fetching data about what is selected, error messages) - algorithm that will find suitable connection (probably A* with cost functions) - Deal with various tagging variants. - Deal with features intersecting without nodes when they should block routing. - Make a proper handling of implicit way splitting (may require user action, but the less the better. Users wouldn't accept to click through hard-to- understand and possibly multiple modal windows). - Make a proper Undo (This one being particular important) - Maybe cope with runtime and/or space constraints Subsequently I would add handling of connection types - fixing bugs reported by user, encountered in released version - modification of algorithm (multiple A* searches? Maybe something smarter and faster would be needed.) - interface (selecting connection type) - loading user-defined connection types in reasonable and editable format - definitions of some obvious types - Making a user interface to handle user-defined connection types, might be a quite large sub-editor). - Fitting that into the various JOSM storage ideas (File format, storage in the central JOSM wiki repository, store in local user preferences). - Probably i18n for the interface parts. - Find sensitive testing case and defend the whole thing on various community mailing lists (I will assist you, but it is inevitable to meet the real needs of various local comunities, and inevitable to make the software really useful). At this point it should be already useful for many tasks and faster than configuring filters to select linear feature consisting of multiple ways. It would depend on how JOSM developers would see it, but it could be at this stage merged into JOSM trunk (in case of backup plan I would release a plugin). I think it would be helpful to first have it as a plugin and see it in action. This allows to proof it has proper encapsulation for the other code parts. That has proven in the past very useful for code maintenance and is therefore common for new and significant improvements). Is there anything that I missed here? Is my plan realistic (GSoC coding starts on 19 May and finishes on 11 August)? Yes, I'm confident that this will work. I'll have a closer look at your proposal in the train tomorrow and then comment as soon as I found my Wifi on the conference venue :) Cheers, Roland ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM plugin public transport update (Google Summer of Code program)
I wonder about checkpoints for good standing with their communities on 19 May, mid-term evaluation on 23 June and final evaluation deadline. Should there be a precise set of what must be be done till 19 May and 23 June, or is it decided based on whatever there is an active development? I assume that to pass final evaluation deadline entire project must be delivered, but how the two previous ones are supposed to be handled? I am unsure what I should write as detailed timeline: how do you plan to spend your summer?. Should I declare when each feature will be finished? Or is it about something else? My proposal is available on http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mateusz_konieczny/5629499534213120 I would appreciate any feedback. - what type was previously selected (i.e. if a user had selected a type X in the past, then this selection will be assumed as more likely the next time) Also a good idea although I would see this rather as choosing which item to highlight. I think that it may be better to avoid forcing user to click in cases when algorithm guessed right without additional data. Additionally, features with certain tags could and should block routing even if they just cross the path without sharing a nnode. Think of a gate (barrier=gate or a military no-go area). I am not sure. In the first case barrier should have either different layer or share node (If a linear barrier crosses a highway, they must connect with a node at intersection. - from Barriers article on wiki), and in the second road should have access tags. Though both cases are currently not reported as a problem by JOSM validator (I filed ticket for the first case, as wiki is quite clear. Second seems to have no suggested solution on wiki, maybe it should be discussed on tagging mailing list). - Deal with various tagging variants. Added as part of defining route types (improving definitions of route types to handle tagging variations). - Deal with features intersecting without nodes when they should block routing. I think that all cases like this are mapping bugs and should be reported by JOSM validator (expecting every single router to parse thing like military no-go areas instead of checking access tags on roads is IMHO a poor idea). - Make a proper handling of implicit way splitting (may require user action, but the less the better. Users wouldn't accept to click through hard-to- understand and possibly multiple modal windows). Added to proposal as implicit way splitting (for nodes that are in the middle of way), with minimal required user action Make a proper Undo (This one being particular important) I am confused here, there is probably no need to revert way selection. Is it about implicit splitting requested during selecting route? I added note about this. Maybe cope with runtime and/or space constraints I mentioned it in the new proposal version (algorithm that will find suitable connection in acceptable time, without too high memory usage). Making a user interface to handle user-defined connection types, might be a quite large sub-editor). I am not sure is it necessary, I thought that types would be edited like validator rules. Possible to do, but 99,9% of users never needs to do it and others may simply edit text file. Fitting that into the various JOSM storage ideas (File format, storage in the central JOSM wiki repository, store in local user preferences). Is is about distributing plugin or is it about how it will work? Or maybe both? - Probably i18n for the interface parts. Now making translations possible is mentioned while discussing interface. - Find sensitive testing case and defend the whole thing on various community mailing lists (I will assist you, but it is inevitable to meet the real needs of various local comunities, and inevitable to make the software really useful). I hope that this one will require changes no bigger than (re)defining route types. I think it would be helpful to first have it as a plugin and see it in action. OK, I will rework proposal to indicate that it is intended to start as a plugin and mention integration into JOSM trunk as potential future goal. Should I mention public transport plugin in proposal as source of this idea? I'll have a closer look at your proposal in the train tomorrow and then comment as soon as I found my Wifi on the conference venue :) Thanks! ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
