On Thu, Jun 23, 2011 at 4:00 AM, WanMil <wmgc...@web.de
<mailto:wmgc...@web.de>> wrote:

    Am 15.06.2011 20:34, schrieb WanMil:

        Am 14.06.2011 22:57, schrieb WanMil:

                Hi,

                    Although I wrote to Brett directly that extending
                    the polygon to 181°
                    works I have observed that is works only for osm
                    input but not for pbf
                    input.

                    osmosis --read-pbf file=180.osm.pbf
                    --bounding-polygon file=asia.poly
                    --write-xml file=filtered.osm
                    throws an exception:

                    SCHWERWIEGEND: Thread for task 1-read-pbf failed

                 > [...snip...]
                 > So the pbf parser should be changed.

                I don't think this is a problem in the PBF parser. It
                just shows up in
                the stack trace because in your pipeline, the PBF reader
                and the poly
                filter are in the same thread. The relevant portion of
                the stack trace
                is:

                    java.lang.__IllegalArgumentException: Bound
                    coordinates outside of valid
                    range
                    at
                    
org.openstreetmap.osmosis.__core.domain.v0_6.Bound.<init>(__Bound.java:72)
                    at
                    
org.openstreetmap.osmosis.__areafilter.v0_6.PolygonFilter.__simpleBoundIn
                    tersect(PolygonFilter.java:__118)
                    at
                    
org.openstreetmap.osmosis.__areafilter.v0_6.PolygonFilter.__process(Polyg
                    onFilter.java:71)


                The Bound class does not or should not really care at
                this point whether
                the data is from PBF or XML or wherever. So if there's a
                bug, it's
                actually in the Bound which has some incorrect argument
                validation code
                or in the PolygonFilter which passes incorrect arguments
                to the Bound,
                not in the PBF reader.

                Could you post your extended polygon with 181° here so I
                can test this?
                Because if it works with XML but not with PBF it gets really
                interesting ;)

                Bye
                Igor


            Hi Igor,

            attached you find the modified poly file.
            I have to add that I tried the XML reader with my test file
            whereas the
            PBF reader was tested with the pbf planet dumpD

            
(ftp://ftp5.gwdg.de/pub/misc/__openstreetmap/planet.__openstreetmap.org/pbf-__experimental/planet-latest.__osm.pbf
            
<ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/pbf-experimental/planet-latest.osm.pbf>

            which I think is dated from June 10th). Maybe that makes a
            difference?

            PBF reading failed with the given exception. XML reading was
            successful
            and the 180° longitude node was successfully transferred to
            the filtered
            file.

            WanMil


        I have found the reason for the problem. It's not pbf related.

        Attached osm file also throws the exception. The reason is the
        bounding
        box information which is not accepted:
        <bound box="-90.00000,-180.00000,90.__00000,180.00000"
        origin="http://www.__openstreetmap.org/api/0.6
        <http://www.openstreetmap.org/api/0.6>"/>

        WanMil


    Are there any plans to fix that problem? From my point of view it
    should be easily fixable by removing the check in the Bound class or
    if the check is less strict. But I don't know if there are any side
    effects.


Perhaps we could simply relax the Bound checks to allow slightly larger
values such as 181 and 91.  It's ugly, but I don't have a better idea.
At least it should catch the majority of error cases.

Any objections?

Brett


Hi,
what need to be done to get this issue fixed?
The following things were provided:
* a simple testcase
* a scenario in which the problem is a real issue (extracting russian border)
* a simple patch based on Brett ideas

I don't know what I can do now to speed up a bugfix. So please commit the patch or let me know what's wrong with it.

Thanks
WanMil

_______________________________________________
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

Reply via email to