Re: [OSM-dev] TRAPI status
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. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
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. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
I don't know what the big fuss is about here. It is indeed sad that the development stops, but it was not the /only/ XAPI/API server out there. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
On Thu, Mar 4, 2010 at 10: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. Cheers, Andy This was already done, and both TRAPI servers that are part of the t...@h load balancer use exactly this process. This is the ugly hack that Blars refers to in his first email. I can send more info if anyone is interested in setting it up. I also plan on updating the wiki with this info as soon as I have a chance. -Jeremy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
In article c4193f8c1003040705n233ad983s51cda0e4fe474...@mail.gmail.com you write: 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? Without the documentation that hasn't yet been written, I'm not sure it would do anyone much good. 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? It shouldn't be much more than 2-3 time as much work as writing the code to fetch the replication diffs properly. That would also require java and a lot of overhead I refuse to add to TRAPI. I should have been clear that my lack of time was the primary reason I stopped developing TRAPI. Coupled with my not wanting to drop everything for an immediate write of code for replication diffs, and thinking that I might be able to get them fixed so they don't double the number of files needed to be fetched, so I just stopped working on TRAPI. Due to my slow internet and systems, it would take me several weeks to do a database import. -- Blars Blarson blar...@scd.debian.net With Microsoft, failure is not an option. It is a standard feature. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
In article 20100304153805.ga12...@hydra.gt.owl.de The files you need more are the state files which are just 20 byte of status information. Plus several k-bytes and several round-trip times of overhead to fetch them. Sometime I think the people who design this stuff have never been on a slow inteernet connection. -- Blars Blarson blar...@scd.debian.net With Microsoft, failure is not an option. It is a standard feature. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
On Thu, Mar 04, 2010 at 01:52:22PM -0800, openstreetmap-...@scd.debian.net wrote: In article 20100304153805.ga12...@hydra.gt.owl.de The files you need more are the state files which are just 20 byte of status information. Plus several k-bytes and several round-trip times of overhead to fetch them. Sometime I think the people who design this stuff have never been on a slow inteernet connection. When running a TRAPI and beeing able to download a multi-gigabyte planet file + downloading a multi-kilobyte diffs per minute would suggest one has a half way speedy connection. Flo -- Florian Lohoff f...@zz.de Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Inconsistency in database?
Has anyone found any more of these? I had a look through the changesets, but the only commonality I could find is they're all tagged as PL in live mode. However 3 is a small sample size - it would be better to have more examples to track down the bug. Or, even better, if anyone can find a repeatable method for reproducing it. Cheers, Matt On Mar 1, 2010 8:49 PM, Frank Bielig frank.bie...@onestepahead.de wrote: Hallo, I found two more inconsistent ways: 45298547: http://api.openstreetmap.org/api/0.6/way/45298547 http://api.openstreetmap.org/api/0.6/way/45298547/1 45770380: http://api.openstreetmap.org/api/0.6/way/45770380 http://api.openstreetmap.org/api/0.6/way/45770380/4 44141527: (from previous mail) http://api.openstreetmap.org/api/0.6/way/44141527 http://api.openstreetmap.org/api/0.6/way/44141527/2 The problem of inconsistency seems to affect more than one way. It might be good idea to fix these special ways in database directly. BR, Frank Hallo, I just checked the way 44141527. Calling http://api.openstreetmap.org/api/0.6/way/4... -- Frank Bielig Tel: +49 33398 687848 OneStepAhead AGFax: +49 33398 687849 Research Development Mobil: +49 177 3339868 Leuschnerstr. 45 eMail: frank.bie...@onestepahead.de D-70176 Stuttgart Web: http://www.OneStepAhead.de Firma: OneStepAhead AG Firmensitz/Amtsgericht:Stuttgart, HRB 22686 Vorstand/Vorsitzender: Nihat Kücük Aufsichtsratvorsitzender: Prof. Dr. Reinhold von Schwerin ___ dev mailing list dev@openstreetmap.org http://list... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TRAPI status
I can send more info if anyone is interested in setting it up. I also plan on updating the wiki with this info as soon as I have a chance. -Jeremy I've gone ahead and updated the wiki. Let me know if anything doesn't make sense. http://wiki.openstreetmap.org/wiki/Trapi -Jeremy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Inconsistency in database?
Hallo Matt, Has anyone found any more of these? I had a look through the changesets, but the only commonality I could find is they're all tagged as PL in live mode. However 3 is a small sample size - it would be better to have more examples to track down the bug. Or, even better, if anyone can find a repeatable method for reproducing it. Unfortunately there are no more examples. I went through the whole database. You can easily check by importing a planet file into a postgres (production schema) using osmosis (--write-apidb). The errors are coming up in completion step when current* tables are filled. Frank On Mar 1, 2010 8:49 PM, Frank Bielig frank.bie...@onestepahead.de mailto:frank.bie...@onestepahead.de wrote: Hallo, I found two more inconsistent ways: 45298547: http://api.openstreetmap.org/api/0.6/way/45298547 http://api.openstreetmap.org/api/0.6/way/45298547/1 45770380: http://api.openstreetmap.org/api/0.6/way/45770380 http://api.openstreetmap.org/api/0.6/way/45770380/4 44141527: (from previous mail) http://api.openstreetmap.org/api/0.6/way/44141527 http://api.openstreetmap.org/api/0.6/way/44141527/2 The problem of inconsistency seems to affect more than one way. It might be good idea to fix these special ways in database directly. BR, Frank Hallo, I just checked the way 44141527. Calling http://api.openstreetmap.org/api/0.6/way/4... -- Frank Bielig Tel: +49 33398 687848 OneStepAhead AGFax: +49 33398 687849 Research Development Mobil: +49 177 3339868 Leuschnerstr. 45 eMail: frank.bie...@onestepahead.de D-70176 Stuttgart Web: http://www.OneStepAhead.de Firma: OneStepAhead AG Firmensitz/Amtsgericht:Stuttgart, HRB 22686 Vorstand/Vorsitzender: Nihat Kücük Aufsichtsratvorsitzender: Prof. Dr. Reinhold von Schwerin ___ dev mailing list dev@openstreetmap.org mailto:dev@openstreetmap.org http://list... -- Frank Bielig Tel: +49 33398 687848 OneStepAhead AGFax: +49 33398 687849 Research Development Mobil: +49 177 3339868 Leuschnerstr. 45 eMail: frank.bie...@onestepahead.de D-70176 Stuttgart Web: http://www.OneStepAhead.de Firma: OneStepAhead AG Firmensitz/Amtsgericht:Stuttgart, HRB 22686 Vorstand/Vorsitzender: Nihat Kücük Aufsichtsratvorsitzender: Prof. Dr. Reinhold von Schwerin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] svn:eol-style=native
Hi, I'd like to set svn:eol-style=native for 481 source files. Any objections? One-third (207) of the files already have this flag. Btw, you can put the following in the subversion config: enable-auto-props = yes *.java = svn:eol-style=native This way all added files get the property by default. __ Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] email addresses in trac
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think the addresses shown in trac ( cc:) are to long and not much of interest for other user. Could you please shorten them somehow that you do almost get the whole address. It is also not really obvious that you can use your user-name instead of email-address and if you are logged it does not offer the username but your email-address. Myself did that mistake, and using that part shown with google easily presents you my whole address Please can someone change my email-address into my username in the archive. Thanks colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuPkFgACgkQalWTFLzqsCvJCwCguFj/7bA0UEuBYTonwDKjNP6E 3QEAoMTpsO0hOCQDelAHOP66Ge+u5vYG =lPOc -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
At 2010-03-03 14:31, Richard Welty wrote: On 3/3/10 4:29 PM, Paul Johnson wrote: Alan Mintz wrote: A similar problem exists with some landuse=* ways that people have glued to roads. I'd call that a bit of an error: Clearly that landuse doesn't continue all the way out to the street centerline. but for people using josm w/the validator who are not aware of the issue, they are told that the duplicate nodes are an error, and there's a convenient fix button right there. Sounds like the validator should take into account the type of features in this case, right? I'm all for joining nodes of like feature types (like landuse to landuse), but it shouldn't tell you (let you?) join landuse to highway. From a technical standpoint, the land parcels do indeed usually extend out to the centerline of the roadway, but an easement is granted to the city/county/state for the road, utilities, etc., and the area within the easement may not be built upon by the landowner. IMO, that should exclude the area within the easement from the landuse boundary. -- Alan Mintz alan_mintz+...@earthlink.net ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On 3/4/10 11:54 AM, Alan Mintz wrote: At 2010-03-03 14:31, Richard Welty wrote: On 3/3/10 4:29 PM, Paul Johnson wrote: Alan Mintz wrote: A similar problem exists with some landuse=* ways that people have glued to roads. I'd call that a bit of an error: Clearly that landuse doesn't continue all the way out to the street centerline. but for people using josm w/the validator who are not aware of the issue, they are told that the duplicate nodes are an error, and there's a convenient fix button right there. Sounds like the validator should take into account the type of features in this case, right? I'm all for joining nodes of like feature types (like landuse to landuse), but it shouldn't tell you (let you?) join landuse to highway. i would agree with you. not being familiar with internals in this case, i don't know how hard that would be to adjust. however, at a minimum, there probably ought to be some sort of documentation/help option available for errors and warnings so a newish user can get immediate feedback on whether a fix is advisable, maybe right click/help-with-error leading to a text help dialog? From a technical standpoint, the land parcels do indeed usually extend out to the centerline of the roadway, but an easement is granted to the city/county/state for the road, utilities, etc., and the area within the easement may not be built upon by the landowner. IMO, that should exclude the area within the easement from the landuse boundary. and from a practical point of view, this is how they are in the database at the present time; nodes for landuse/areas are at the same locations as nodes in highways. richard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Richard Welty schrieb: On 3/4/10 11:54 AM, Alan Mintz wrote: At 2010-03-03 14:31, Richard Welty wrote: From a technical standpoint, the land parcels do indeed usually extend out to the centerline of the roadway, but an easement is granted to the city/county/state for the road, utilities, etc., and the area within the easement may not be built upon by the landowner. IMO, that should exclude the area within the easement from the landuse boundary. and from a practical point of view, this is how they are in the database at the present time; nodes for landuse/areas are at the same locations as nodes in highways. I came accross this, too, and have to say it is quite a lot of work to get the landuse of the road and often you get conflicts later on these areas again. Maybe a tool for unglueing those objects and moving the area aubout 2 meters of would be nice or even a automatical fix by josm itself. Also validator warns about landuses glued together if there exists nothing else and these landuses should be glued you get warnings about them. cheers colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuP8FQACgkQalWTFLzqsCsBPQCguEasIjHG0peW+mRHXwLvwy9J 708An3kFqEcKz0VFX4U1vxuLj87pb8e8 =/e0l -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] svn:eol-style=native
Hi, that's fine for me. I've now updated my local SVN config too. Regards Karl Am 04.03.2010 11:16, schrieb Sebastian Klein: Hi, I'd like to set svn:eol-style=native for 481 source files. Any objections? One-third (207) of the files already have this flag. Btw, you can put the following in the subversion config: enable-auto-props = yes *.java = svn:eol-style=native This way all added files get the property by default. __ Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On Thu, Mar 04, 2010 at 06:39:34PM +0100, colliar wrote: Richard Welty schrieb: On 3/4/10 11:54 AM, Alan Mintz wrote: At 2010-03-03 14:31, Richard Welty wrote: From a technical standpoint, the land parcels do indeed usually extend out to the centerline of the roadway, but an easement is granted to the city/county/state for the road, utilities, etc., and the area within the easement may not be built upon by the landowner. IMO, that should exclude the area within the easement from the landuse boundary. and from a practical point of view, this is how they are in the database at the present time; nodes for landuse/areas are at the same locations as nodes in highways. I came accross this, too, and have to say it is quite a lot of work to get the landuse of the road and often you get conflicts later on these areas again. Maybe a tool for unglueing those objects and moving the area aubout 2 meters of would be nice or even a automatical fix by josm itself. +1. Some days ago, I came across a mkgmap warning for a dead-end oneway in a residential area that was riddled with landuse polygons that shared points with ways. It was very hard to see that the oneway was not connected to the road it was supposed to. I spent several minutes detaching the landuses from the roads in the area. Marko ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Previous presets still available?
Hi! After switching to a recent version of JOSM, I noted that the presets have changed to a different structure. I liked some of the old presets better, e.g. the ability to set a track/tracktype with one click - which has become much more complicated with the new presets. Are the previous presets already available as an option somewhere or should I extract them from an old JOSM build? If it's the latter: With which version did the presets change? bye Nop -- View this message in context: http://n2.nabble.com/Previous-presets-still-available-tp4677821p4677821.html Sent from the JOSM Development mailing list archive at Nabble.com. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
At 2010-03-04 09:10, Richard Welty wrote: On 3/4/10 11:54 AM, Alan Mintz wrote: From a technical standpoint, the land parcels do indeed usually extend out to the centerline of the roadway, but an easement is granted to the city/county/state for the road, utilities, etc., and the area within the easement may not be built upon by the landowner. IMO, that should exclude the area within the easement from the landuse boundary. and from a practical point of view, this is how they are in the database at the present time; nodes for landuse/areas are at the same locations as nodes in highways. Some imported ones, yes. I doubt human-drawn ones are (I certainly don't do it). It would be nice if someone would create a tool that lets you select two nodes, specify a direction and distance, and have it dup and move them, as well as the specified way that connects them. It should also be possible to have it do the same thing with an entire polygon and/or, in the case where it is rectangular, specify separate easement distances for all 4 sides (this would be the most common usage). This would greatly speed up fixing of these types of issues when they are encountered by the more experienced of us. -- Alan Mintz alan_mintz+...@earthlink.net ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
