[Taginfo-dev] [joto/taginfo] c67201: Add translations to view keys, and the correspondi...
Branch: refs/heads/master Home: https://github.com/joto/taginfo Commit: c67201f5c8704132cda1cf5bf896d17037bf33e7 https://github.com/joto/taginfo/commit/c67201f5c8704132cda1cf5bf896d17037bf33e7 Author: Jocelyn Jaubert jocelyn.jaub...@gmail.com Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: M web/i18n/en.yml M web/i18n/fr.yml M web/views/key.erb Log Message: --- Add translations to view keys, and the corresponding french translation Commit: 942f11308a13b43a81094d17670c9a577334be2f https://github.com/joto/taginfo/commit/942f11308a13b43a81094d17670c9a577334be2f Author: Jocelyn Jaubert jocelyn.jaub...@gmail.com Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: M web/i18n/en.yml M web/i18n/fr.yml M web/public/js/taginfo.js M web/taginfo.rb M web/views/key.erb M web/views/tag.erb Log Message: --- Add more translation in javascript code Commit: 15ef8b0d51f9610f52b8e94ba16691f4e512f0d0 https://github.com/joto/taginfo/commit/15ef8b0d51f9610f52b8e94ba16691f4e512f0d0 Author: Jocelyn Jaubert jocelyn.jaub...@gmail.com Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: M web/taginfo.rb Log Message: --- Add translation on wiki description, falling back to english Commit: 2132d1c6d0199a8dc8b4d7a13e1bbb327a1fe1b3 https://github.com/joto/taginfo/commit/2132d1c6d0199a8dc8b4d7a13e1bbb327a1fe1b3 Author: Jochen Topf joc...@topf.org Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: M web/i18n/en.yml Log Message: --- fix regression Commit: 4c5b5e2ebb156569a1ac8071b208d318de264fa6 https://github.com/joto/taginfo/commit/4c5b5e2ebb156569a1ac8071b208d318de264fa6 Author: Jochen Topf joc...@topf.org Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: M web/lib/sources.rb M web/lib/utils.rb M web/views/apidoc.erb M web/views/download.erb Log Message: --- add rel=nofollow to external and download links Commit: d5a47e37084a482bf4d7ff4b17b8d1fdd6a6dd49 https://github.com/joto/taginfo/commit/d5a47e37084a482bf4d7ff4b17b8d1fdd6a6dd49 Author: Jochen Topf joc...@topf.org Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: A bin/check-translations.rb Log Message: --- Add script to help find missing translations. Commit: cca8bdb74b917326ce0df3890dc7f079bf4cbdc7 https://github.com/joto/taginfo/commit/cca8bdb74b917326ce0df3890dc7f079bf4cbdc7 Author: Jochen Topf joc...@topf.org Date: 2011-10-26 (Wed, 26 Oct 2011) Changed paths: M README M web/i18n/de.yml M web/i18n/en.yml Log Message: --- Some more german translations. Compare: https://github.com/joto/taginfo/compare/373a6ac...cca8bdb ___ Taginfo-dev mailing list Taginfo-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/taginfo-dev
[OSM-dev] How to Develop a Plugin for JOSM
Hi, I try to develop a little plugin for JOSM by using the developersguide (http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins), but I am facing some problems. My first problem concerns setting up the plugin environment. I have checked out the plugin environment with Eclipse. The Problem is, that the autocorrect of Eclipse doesn't work in the environment. For exempal if i change some code in the existing plugins, my errors are not shown. The icons of the classes are also a little different then usually (they have a hollow J). Did I make some mistake by checking out the environment? Can somebody please give me a little tutorial how to start developing a JOSM Plugin with Ecllipse? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How to Develop a Plugin for JOSM
On Wed, Oct 26, 2011 at 8:59 AM, Joerg Moldenhauer moldenha...@cip.ifi.lmu.de wrote: Hi, I try to develop a little plugin for JOSM by using the developersguide (http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins), but I am facing some problems. My first problem concerns setting up the plugin environment. I have checked out the plugin environment with Eclipse. The Problem is, that the autocorrect of Eclipse doesn't work in the environment. For exempal if i change some code in the existing plugins, my errors are not shown. The icons of the classes are also a little different then usually (they have a hollow J). Did I make some mistake by checking out the environment? Can somebody please give me a little tutorial how to start developing a JOSM Plugin with Ecllipse? I'm not at home so I don't have the details of my setup in front of me but I do recall the videos on the developer guide page being a big help: http://josm.openstreetmap.de/wiki/DevelopersGuide I believe I checked out the JOSM source from the JOSM svn repository and the plugin I wanted to modify came from the OSM repository. Toby ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi! I'm wondering how osm2pgsql determines the direction of a route. Has the order of way-refs in the route relation influence on that? Are role tags forward and backward evaluated? Markus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi, On 10/26/11 16:27, mar...@gmx.eu wrote: I'm wondering how osm2pgsql determines the direction of a route. Has the order of way-refs in the route relation influence on that? osm2pgsql takes all the ways making up the route relation and throws them into the GEOS LineMerge operation, documented here: http://geos.refractions.net/ro/doxygen_docs/html/classgeos_1_1operation_1_1linemerge_1_1LineMerger.html The result is a number of LineString geometries (at least one, at most the number of relation members). The direction of each resulting LineString should be the direction of the majority of constituting ways. Are role tags forward and backward evaluated? Not at all. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How to Develop a Plugin for JOSM
On Wed, Oct 26, 2011 at 8:59 AM, Joerg Moldenhauer moldenha...@cip.ifi.lmu.de wrote: Hi, I try to develop a little plugin for JOSM by using the developersguide (http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins), but I am facing some problems. My first problem concerns setting up the plugin environment. I have checked out the plugin environment with Eclipse. The Problem is, that the autocorrect of Eclipse doesn't work in the environment. For exempal if i change some code in the existing plugins, my errors are not shown. The icons of the classes are also a little different then usually (they have a hollow J). Did I make some mistake by checking out the environment? Can somebody please give me a little tutorial how to start developing a JOSM Plugin with Ecllipse? I'm not at home so I don't have the details of my setup in front of me but I do recall the videos on the developer guide page being a big help: http://josm.openstreetmap.de/wiki/DevelopersGuide I believe I checked out the JOSM source from the JOSM svn repository and the plugin I wanted to modify came from the OSM repository. Toby ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev Thanks for your quick reply! I know the videos and tried to follow them. Checking out JOSM and building it worked just fine (however Eclipse found some mistakes in the code). Unfortunately I could not build the OSB Plugin according to the video, because the file build.properties was missing. (I tried to use the plugin environment, because that was recommended in the developers guide. Has somebody experience in that? Or is the way described in the videos just better?) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Thanks, this helps a lot! The direction of each resulting LineString should be the direction of the majority of constituting ways. That explains a some issues in openptmap at zoom level 17. Are role tags forward and backward evaluated? Not at all. Could it be done in osm2pgsql somehow? The new public transport schema makes it necessary to take the member roles into account. Most of them are redundant; it would suffice to read the role of the first listed way and to use this role when determining the direction of the LineString. This would be the rule: - First way has role forward: The whole LineString inherits the direction from this way. - First way has role backward: The whole LineString inherits the opposite direction from this way. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi, The new public transport schema makes it necessary to take the member roles into account. are you sure? I thought one of the major goals of the _new_ PT schema was precisely to eliminate this forward/backward mess with the relation per route variant concept. Just looked it up [1]: The roles alternate, forward and backward should not be used any more. On the public transport page it says basically the same in other words, however the Relation:route still has all those forward:stop:42 crazy roles which have been added at some time in 2008/2009, long time before what we now call the new PT schema was even proposed. I think that wiki page is wrong/outdated, but that's not a dev issue, clearly :) I know, there still are lots of forwards and backwards out there... but it's the _old_ PT schema, not the new one that requires them. Bye Igor [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi, On 10/26/2011 05:22 PM, mar...@gmx.eu wrote: Could it be done in osm2pgsql somehow? Of course it *could* ;) Problem is that I have the impression that there are a number of non-compatible uses of all sorts of roles with regard to relations (forward/backward, or even north/south/east/west in the US) and I am unsure if this can be handled generally. Some people seem to use backward as this way has to be reversed to form a linestring with the others, while others seem to use backward as the bus only uses this section of road on the return journey. But I have not systematically looked into this. Someone should perhaps do that. - Most route relations are probably not directional (cycle routes come to mind). 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: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi Igor, are you sure? I thought one of the major goals of the _new_ PT schema was precisely to eliminate this forward/backward mess with the relation per route variant concept. Just looked it up [1]: No, I'm indeed very unsure in aspects of the new schema. If the ways don't have roles, the direction of the route will have to be determined based alone on the sequence of ways in the route. A work-around would be to check the direction of the LineString right after its creation. Something like this: IF the first noderef of the LineString is identical to the first or last noderef of the first referenced way of the underlying relation THEN change the LineStrings direction Right? Or am I wrong again? Please help... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Overpass API delivers randomly invalid data
Hi, We are querying data for a bounding box and randomly entries are delivered as way id=30134048 or node id=31881194 lat=47.5137295 lon=11.3250178/ The entries are cut before the version attribute. If we query the entries with the id all attributes are delivered. I've tried to reproduce this. But all changesets I have receieved have complete meta data. So could you please give more detailed information, in particular - At what time as exactly as possible have you tried to download? There have been an outage on Sunday including a backlog for meta data until Monday evening, and I would need to figure out whether it is related to this or not. - Which query exactly failed? - Does is fail sometimes or reproducably? - Are in a damaged response no meta data at all or is it partly missing? Best regards, Roland ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
On Wed, Oct 26, 2011 at 5:47 PM, Frederik Ramm frede...@remote.org wrote: this way has to be reversed to form a linestring with the others, more like the direction of the route is with/against the direction of the underlying way while others seem to use backward as the bus only uses this section of road on the return journey. Which is, and always has been, completely stupid. But I have not systematically looked into this. Someone should perhaps do that. - Most route relations are probably not directional (cycle routes come to mind). Bear in mind that cycle routes are one of the earliest and heaviest users of forward/backward roles. It is easy to find them on opencyclemap, e.g. at http://osm.org/go/euu4OUOi?layers=C I'm disappointed to see that whoever came up with the new PT schema didn't understand what these roles are useful for, which was nothing to do with the overall route characteristics (towards or away from one particular place), instead they are for expressing the relation between the direction of travel and the direction of the way. The separation of every bus routes into two bus routes, one for each direction, even when they are simply duplications of one another, is surely a waste of time and effort. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
On Wed, Oct 26, 2011 at 06:36:56PM +0100, Andy Allan wrote: [...] between the direction of travel and the direction of the way. The separation of every bus routes into two bus routes, one for each direction, even when they are simply duplications of one another, is surely a waste of time and effort. Most bus routes will not be exact duplications. For instance if the route goes through a roundabout or over a road with two different ways for the different directions. So we need the option of having two relations, one for each direction anyway. And that case will be the one used most often. So having always two relations is conceptually much easier. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi, On 10/26/2011 07:03 PM, mar...@gmx.eu wrote: IF the first noderef of the LineString is identical to the first or last noderef of the first referenced way of the underlying relation THEN change the LineStrings direction Bear in mind that - at least for osm2pgsql which knows nothing about special public transport relations - a relation generally resolves to a MultiLineString which does not really have a first noderef. I have the impression that we should organise a hack weekend specifically for public transport. All this someone cooks up a new schema on the Wiki without discussing it with anybody else doesn't seem to give results. 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: [OSM-dev] osm2pgsql, direction of a virtual way (based on a route)
Hi Markus, No, I'm indeed very unsure in aspects of the new schema. If the ways don't have roles, the direction of the route will have to be determined based alone on the sequence of ways in the route. Yes, this is the only feasible way I can think of with PT routes if you don't have roles. This is also the way the new PT schema does this. Once the route uses the same OSM way more than once, you will find it very difficult to figure out automatically how the route goes. Bus routes use the same way multiple times all the time, and train routes do it as well, albeit rarely (Munich's S3 and S7 at Ostbahnhof being an example). A work-around would be to check the direction of the LineString right after its creation. Something like this: IF the first noderef of the LineString is identical to the first or last noderef of the first referenced way of the underlying relation THEN change the LineStrings direction Right? Or am I wrong again? Please help... I think you mean IF the _last_ noderef ... :) Yes, that might work. It's still a heuristic though, taking advantage of the fact that the probability that the first way member is correct in terms of route directionality is higher than that overall relation member order is correct. Still, that assumes that you have exactly one LineString for a route in the first place. And as far as I understand the GEOS LineMerger documentation, its algorithm won't work for multiply-used ways (at least there are some not-so-uncommon cases I am absolutely sure it won't work). It won't crash but it'll return multiple geometries which you'll need to sew together and orientate with some other algorithm. Which gets us back to square one :( I wouldn't even try to figure it out, I'd fail fast... I would just take the relation order and try to assemble it way by way. If it doesn't work (you can at least determine _that_ reliably :)), so bad luck, the relation is broken, can't render that route. Well, you still can render it (it's a bunch of LineStrings after all), but you can't draw arrows that show which direction it goes. And you could put a marker on it a la KeepRight so someone can go and fix it :) Bye Igor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Plugin for Karlsruhe schema
On Tue, Oct 25, 2011 at 11:43:48PM +0200, Hartmut Holzgraefe wrote: Not saying that such a plugin doesn't make sense for certain areas in the world, but i haven't seen this by linear distance scheme in any place but the USA yet, so its probably low priority for the rest of the world, and definitely for all parts of Europe i've been to ... For what it is worth, Finland uses a somewhat similar numbering scheme in rural areas. If I remember correctly, the house number increments by one for every 10 metres from the start of the road. But, you can still have a,b,c suffixes to the house number if there are several houses sharing the same driveway to the rural road. So, I guess that the interpolation line would be helpful until someone fills in the real house numbers and driveways. Marko ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
