Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker, good to see that the code in WrongAngleFixer is reviewed. I am sure it can be improved. Just keep in mind that it sometimes finds out that it is better to place the "moved" point on top of another. If this happens with routing nodes you need a way to calculate the bearing values "between" these points. If you decide to remove the information from the coords you probably have to store it in the way. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 25. Februar 2017 18:17:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd Sorry about the delay in replying. Thoughts on some of this. Assuming the MapRes and highRes are related by powers of 2, and all the rounding is done consistently, there should never be any difference between going via highRes to get from the original doubleFloat value to a MapRes value. The most consistent rounding in mkgmap code is to the closest whole number with x.5 rounding up towards plus infinity. This is also the definition of Math.round(). So, it would be much clearer and have the same effect if old:imgFmt.Utils.toMapUnit new:Coord.toHighPrec were re-coded as return Math.round(degrees / 360.0D * (1 << resolution)) Other cases of rounding should be checked - esp. Utils.roundup()), which I thought was wrong, but looking again seems OK. This effects how the base Lat/Lon for a subdivision is held - should be a correctly rounded value. In the new versions of Coord.getLatitude/Longitude(), could have/use final int DELTA_HALF = 1 << (DELTA_SHIFT - 1); I'm still studying the wrongAngleFixer/AlternativePos/DisplayedCoord stuff, but getting a little bit lost as to when need to keep the all the flags in the copy of the Coord and when not (ie getDisplayedCoord loses all the flags and highPrec info) and what is taken into account for the distance() function I have this feeling that Coord shouldn't have all this INC/DEC_LAT/LON stuff but wrongAngleFixer just make up an adjacent Coord if it does a better job Ticker On Fri, 2017-02-24 at 10:54 +, Gerd Petermann wrote: > Hi Ticker, > > okay, here are my findings so far: > 1) We assume that the double values read from OSM or polist (*.mp) > format are precise > 2) The code in the Coord class tries to reduce rounding errors. It > calculates both the 24 values AND the high prec values > from the given doubles. An alternative would be to calculate only the > high prec values from the doubles and then > calculate the 24 bit values by shifting, but that would in fact mean > that the value is rounded two times. In some edge cases > you will get different 24 values doing this. The delta values are > stored in the Coord instance and for 30 bits precision > they are -32 <= delta < 32. > The picture grid1 shows some OSM elements and the Garmin Grid (24 bit > resolution): > http://files.mkgmap.org.uk/download/335/grid1.png > and what the "normal" rounding does (note the zig-zagging rails) > http://files.mkgmap.org.uk/download/336/grid2.png > > 3) The method Coord.getAlternativePositions() called by > WrongAngleFixer introduces some additional problems: > It creates Coord instances where the delta values can be up to 63 ( > -63 <= delta < 63). This sounds much, but it only happens for OSM > nodes > which are far from any Garmin grid point. Imagine that an OSM node > lies exactly in the center of four Garmin grid points. > All four would have the same rounding error, but the distance between > them can be ~2.3 m. > Which of the four Garmin points should be returned by the > Coord.getDisplayedCoord() method? > For a single POI like a natural=peak it doesn't really matter, but > for a node which is part of a roundabout or a railway=rail > you want to get the point which "looks" better. A human knows by > experience that rails are not zig-zagging, so > the goal of the WrongAngleFixer is find the Garmin point which causes > the smallest errors in the angles. > This is not only done for points which lie exactly in the center of > Garmin grid points, but for all which are not close to one such > point. > The WrongAngleFixer uses a iterative try-error approach to find those > nodes which should be "moved", and it needs to know the > "original" position. I found no performant way to implement that with > hashmaps, so I decided to code what we have now. > The improved result looks like this: > http://files.mkgmap.org.uk/download/337/grid3.png > > Later in the data flow the routines for the road network also need to > know the real positions when they calculate the bearing values. > > In short: I found no better solution, it works quite well but one has >
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd Sorry about the delay in replying. Thoughts on some of this. Assuming the MapRes and highRes are related by powers of 2, and all the rounding is done consistently, there should never be any difference between going via highRes to get from the original doubleFloat value to a MapRes value. The most consistent rounding in mkgmap code is to the closest whole number with x.5 rounding up towards plus infinity. This is also the definition of Math.round(). So, it would be much clearer and have the same effect if old:imgFmt.Utils.toMapUnit new:Coord.toHighPrec were re-coded as return Math.round(degrees / 360.0D * (1 << resolution)) Other cases of rounding should be checked - esp. Utils.roundup()), which I thought was wrong, but looking again seems OK. This effects how the base Lat/Lon for a subdivision is held - should be a correctly rounded value. In the new versions of Coord.getLatitude/Longitude(), could have/use final int DELTA_HALF = 1 << (DELTA_SHIFT - 1); I'm still studying the wrongAngleFixer/AlternativePos/DisplayedCoord stuff, but getting a little bit lost as to when need to keep the all the flags in the copy of the Coord and when not (ie getDisplayedCoord loses all the flags and highPrec info) and what is taken into account for the distance() function I have this feeling that Coord shouldn't have all this INC/DEC_LAT/LON stuff but wrongAngleFixer just make up an adjacent Coord if it does a better job Ticker On Fri, 2017-02-24 at 10:54 +, Gerd Petermann wrote: > Hi Ticker, > > okay, here are my findings so far: > 1) We assume that the double values read from OSM or polist (*.mp) > format are precise > 2) The code in the Coord class tries to reduce rounding errors. It > calculates both the 24 values AND the high prec values > from the given doubles. An alternative would be to calculate only the > high prec values from the doubles and then > calculate the 24 bit values by shifting, but that would in fact mean > that the value is rounded two times. In some edge cases > you will get different 24 values doing this. The delta values are > stored in the Coord instance and for 30 bits precision > they are -32 <= delta < 32. > The picture grid1 shows some OSM elements and the Garmin Grid (24 bit > resolution): > http://files.mkgmap.org.uk/download/335/grid1.png > and what the "normal" rounding does (note the zig-zagging rails) > http://files.mkgmap.org.uk/download/336/grid2.png > > 3) The method Coord.getAlternativePositions() called by > WrongAngleFixer introduces some additional problems: > It creates Coord instances where the delta values can be up to 63 ( > -63 <= delta < 63). This sounds much, but it only happens for OSM > nodes > which are far from any Garmin grid point. Imagine that an OSM node > lies exactly in the center of four Garmin grid points. > All four would have the same rounding error, but the distance between > them can be ~2.3 m. > Which of the four Garmin points should be returned by the > Coord.getDisplayedCoord() method? > For a single POI like a natural=peak it doesn't really matter, but > for a node which is part of a roundabout or a railway=rail > you want to get the point which "looks" better. A human knows by > experience that rails are not zig-zagging, so > the goal of the WrongAngleFixer is find the Garmin point which causes > the smallest errors in the angles. > This is not only done for points which lie exactly in the center of > Garmin grid points, but for all which are not close to one such > point. > The WrongAngleFixer uses a iterative try-error approach to find those > nodes which should be "moved", and it needs to know the > "original" position. I found no performant way to implement that with > hashmaps, so I decided to code what we have now. > The improved result looks like this: > http://files.mkgmap.org.uk/download/337/grid3.png > > Later in the data flow the routines for the road network also need to > know the real positions when they calculate the bearing values. > > In short: I found no better solution, it works quite well but one has > to think twice if he needs the Garmin position or the high prec (OSM) > position. > > Worth noting is that the WrongAngleFixer is called for lines and > shapes, but at different stages. > For lines (and roads), it is called before MapLine instances are > created. For shapes, it is called by the ShapeMergeFilter > which is called after all the sub division splitting happened. > That means In the current code (r3820), the ShapeSplitter doesn't > have to care about "moved" points in shapes. > > Gerd > > Von: mkgmap-dev im Auftrag > von Gerd Petermann > Gesendet: D
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker, okay, here are my findings so far: 1) We assume that the double values read from OSM or polist (*.mp) format are precise 2) The code in the Coord class tries to reduce rounding errors. It calculates both the 24 values AND the high prec values from the given doubles. An alternative would be to calculate only the high prec values from the doubles and then calculate the 24 bit values by shifting, but that would in fact mean that the value is rounded two times. In some edge cases you will get different 24 values doing this. The delta values are stored in the Coord instance and for 30 bits precision they are -32 <= delta < 32. The picture grid1 shows some OSM elements and the Garmin Grid (24 bit resolution): http://files.mkgmap.org.uk/download/335/grid1.png and what the "normal" rounding does (note the zig-zagging rails) http://files.mkgmap.org.uk/download/336/grid2.png 3) The method Coord.getAlternativePositions() called by WrongAngleFixer introduces some additional problems: It creates Coord instances where the delta values can be up to 63 (-63 <= delta < 63). This sounds much, but it only happens for OSM nodes which are far from any Garmin grid point. Imagine that an OSM node lies exactly in the center of four Garmin grid points. All four would have the same rounding error, but the distance between them can be ~2.3 m. Which of the four Garmin points should be returned by the Coord.getDisplayedCoord() method? For a single POI like a natural=peak it doesn't really matter, but for a node which is part of a roundabout or a railway=rail you want to get the point which "looks" better. A human knows by experience that rails are not zig-zagging, so the goal of the WrongAngleFixer is find the Garmin point which causes the smallest errors in the angles. This is not only done for points which lie exactly in the center of Garmin grid points, but for all which are not close to one such point. The WrongAngleFixer uses a iterative try-error approach to find those nodes which should be "moved", and it needs to know the "original" position. I found no performant way to implement that with hashmaps, so I decided to code what we have now. The improved result looks like this: http://files.mkgmap.org.uk/download/337/grid3.png Later in the data flow the routines for the road network also need to know the real positions when they calculate the bearing values. In short: I found no better solution, it works quite well but one has to think twice if he needs the Garmin position or the high prec (OSM) position. Worth noting is that the WrongAngleFixer is called for lines and shapes, but at different stages. For lines (and roads), it is called before MapLine instances are created. For shapes, it is called by the ShapeMergeFilter which is called after all the sub division splitting happened. That means In the current code (r3820), the ShapeSplitter doesn't have to care about "moved" points in shapes. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Dienstag, 21. Februar 2017 20:01:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Ticker, okay, I'll try to find out (again) why I decided to do the move only in low-prec. I know that I was not happy with that, but I forgot the reason. I think one was that the WrongAngleFixer started to move points too far. Anyway, I should fix this first. I started to go for 32 bits because some algos which I coded for JOSM use this res. It seemed easier to change mkgmap to also use 32 bits, but I am no longer sure about that. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost. Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near. Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains(). Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list m
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker, okay, I'll try to find out (again) why I decided to do the move only in low-prec. I know that I was not happy with that, but I forgot the reason. I think one was that the WrongAngleFixer started to move points too far. Anyway, I should fix this first. I started to go for 32 bits because some algos which I coded for JOSM use this res. It seemed easier to change mkgmap to also use 32 bits, but I am no longer sure about that. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost. Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near. Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains(). Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot of changes throughout the code and a run-time cost. Manipulating high-res deltas such that the rounded values diverges from the the std lat/long value seems very wrong (is this what it does, or does it simply change one but not the other). Maybe wrong-angle stuff should be looked at to see if there is a better way. This is an area I've never been near. Would be great if Area/bounds and Coord used the same (high-prec) units and there was no ambiguity about contains(). Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Andrzej, sounds possible, but would require lots of difficult changes. That's the problem, each possible way seems to include lots of changes :-( I think the first step is to code more unit tests ... Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Dienstag, 21. Februar 2017 13:13:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd, could you really make a map, which include both +180 and -180 coordinates? I create a map of Asia and I intentionally limit area to 179., because of compilation problems. Maybe if you limit input data that way, that you never process -180 and +180 at the same time, then you could ignore double meaning of +-180? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd, could you really make a map, which include both +180 and -180 coordinates? I create a map of Asia and I intentionally limit area to 179., because of compilation problems. Maybe if you limit input data that way, that you never process -180 and +180 at the same time, then you could ignore double meaning of +-180? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Andrzej, no, it causes lots of problems. For example, the bounding box for planet is (-90.0, -180.0, 90.0, 180.0). If we don't distinct the positions of the left side from the right the area is a line with width 0. The funny thing is that the precision in OSM doesn't even use all possible 32 bit integers, only those for -180 * 10_000_000 to 180 * 10_000_000 so the extreme values near Integer.MAX_VALUE are never used (at least that is the conversion done in pbf or o5m format). I think about using this format for Coord and maybe also Area. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Dienstag, 21. Februar 2017 12:23:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch Hi Gerd, > I found new problems, e.g. 180.0 degrees and -180.0 degrees started > to give the same 32 bit value. Isn't it good? The same is true for 24 bit precision and even for 8bit angles. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd, > I found new problems, e.g. 180.0 degrees and -180.0 degrees started > to give the same 32 bit value. Isn't it good? The same is true for 24 bit precision and even for 8bit angles. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
I thought about this for a while and I am still not sure where to go.
One problem with the high-prec stuff is that it is missleading.
When I started to code the highprec() code my only intention was to be able to
retreive "the original" position as coded in OSM.
You probably learned it the hard way that the value returned by
Coord.getLatitude()
sometimes is different to the value from a rounded Coord.getHighPrecLat() .
The reason is that functions like Coord.getAlternativePositions() used by
WrongAngleFixer
create Coord instances with the same highprec positions but different rounding
(a bit more to
the left or right, a bit more up or down). The idea is that the map looks
better when
the error for that single point is increased. A good place to check this are
multiple parallel rails.
I am still trying to find good code to calculate the bounding box for coords
with this special case.
When such a point is close to or "on" the bounding box in one precision it
might be outside
with the other. I wonder if it would be better to use low precision as soon as
possible.
If you have a good idea for that please let me know.
In the meantime I have found some reasons to change precision from 30 to 32 bit
as this helps when
checking mp-relations. I found new problems, e.g. 180.0 degrees and -180.0
degrees started to give the
same 32 bit value. Working on that now...
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 15:49:10
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Thoughts were:
I was having problems with a multi-polygon relation where OSM showed a
very small gap between 2 parts, but some final cutting of the shape
found that these lines now intersected, and I thought it could be a
mapPrec vs highPrec problem where the multiPolygonRelation logic is
looking for this sort of thing. Changing it to highPrec didn't fix it
(you found that the problem was roundCoord filter) but the changes
looked worth keeping because:
MultiPolygon cutting to expose holes uses highPrec and it seemed best
to be consistent, avoiding cuts that might leave very small areas.
A general move in the direction of all coordinates/bounds/etc being the
held only in highPrec and resolution 24 not being a special case.
But I don't have strong feelings about it.
Ticker
On Fri, 2017-02-17 at 13:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I did not see an advantage in using high-prec. Why do you think it
> should be used?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 13:27:28
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> Yes - sorry, my fault.
> I've just tested a fix to this and the sea is OK now. Is is worth
> keeping the high-res changes in the split-shape branch pending more
> work on MultiPolygonRelation? If so I'll commit.
>
> Ticker
>
>
> On Fri, 2017-02-17 at 10:49 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > problem is in these lines:
> > if (remove) {
> > // check if the polygon contains
> > the
> > complete bounding box
> > if
> > (w.getBounds().contains(tileArea.getBounds())) {
> > remove = false;
> > }
> > }
> > 1) The SeaGenerator creates an outer way which is larger than the
> > tile bounds.
> > 2) This test was wrong because w.getBounds() returns a bbox in
> > highprec values and tileArea.getBounds() is in Garmin units
> >
> > Gerd
> > ____________
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Freitag, 17. Februar 2017 11:00:49
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Gerd
> >
> > Good.
> >
> > Ticker
> >
> > On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > attached is the patch I've created with help of svn.
> > > It only reverts the changes made to MultiPolygonRelation in
> > > r3771.
> > >
> > > I don't know yet why they cause trouble.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Ticker Berkin
> > > Gesendet: Freitag, 17. Feb
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Thoughts were:
I was having problems with a multi-polygon relation where OSM showed a
very small gap between 2 parts, but some final cutting of the shape
found that these lines now intersected, and I thought it could be a
mapPrec vs highPrec problem where the multiPolygonRelation logic is
looking for this sort of thing. Changing it to highPrec didn't fix it
(you found that the problem was roundCoord filter) but the changes
looked worth keeping because:
MultiPolygon cutting to expose holes uses highPrec and it seemed best
to be consistent, avoiding cuts that might leave very small areas.
A general move in the direction of all coordinates/bounds/etc being the
held only in highPrec and resolution 24 not being a special case.
But I don't have strong feelings about it.
Ticker
On Fri, 2017-02-17 at 13:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I did not see an advantage in using high-prec. Why do you think it
> should be used?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 13:27:28
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> Yes - sorry, my fault.
> I've just tested a fix to this and the sea is OK now. Is is worth
> keeping the high-res changes in the split-shape branch pending more
> work on MultiPolygonRelation? If so I'll commit.
>
> Ticker
>
>
> On Fri, 2017-02-17 at 10:49 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > problem is in these lines:
> > if (remove) {
> > // check if the polygon contains
> > the
> > complete bounding box
> > if
> > (w.getBounds().contains(tileArea.getBounds())) {
> > remove = false;
> > }
> > }
> > 1) The SeaGenerator creates an outer way which is larger than the
> > tile bounds.
> > 2) This test was wrong because w.getBounds() returns a bbox in
> > highprec values and tileArea.getBounds() is in Garmin units
> >
> > Gerd
> > ____________________
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Freitag, 17. Februar 2017 11:00:49
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Gerd
> >
> > Good.
> >
> > Ticker
> >
> > On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > attached is the patch I've created with help of svn.
> > > It only reverts the changes made to MultiPolygonRelation in
> > > r3771.
> > >
> > > I don't know yet why they cause trouble.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Ticker Berkin
> > > Gesendet: Freitag, 17. Februar 2017 10:32:11
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Gerd
> > >
> > > Yes - if that fixes it.
> > > But
> > > in r3771 were there a couple of other changes not to
> > > MultiPolygon...
> > > haven't a lot more changes been made since to MultiPolygon...
> > >
> > > Ticker
> > >
> > >
> > > On Fri, 2017-02-17 at 09:19 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > I think the problems were introduced with the highprec changes
> > > > in
> > > > MultiPolygonRelation in r3771.
> > > > When I revert those the problem is gone. If you don't mind I
> > > > commit
> > > > this revert.
> > > >
> > > > Gerd
> > > >
> > > > Von: mkgmap-dev im
> > > > Auftrag
> > > > von Gerd Petermann
> > > > Gesendet: Freitag, 17. Februar 2017 10:02:38
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > > branch
> > > >
> > > > Hi Ticker,
> > > >
> > > > don't need test data, found out what you meant.
> > > >
> > > > Gerd
> > > > ___
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
I did not see an advantage in using high-prec. Why do you think it should be
used?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 13:27:28
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - sorry, my fault.
I've just tested a fix to this and the sea is OK now. Is is worth
keeping the high-res changes in the split-shape branch pending more
work on MultiPolygonRelation? If so I'll commit.
Ticker
On Fri, 2017-02-17 at 10:49 +, Gerd Petermann wrote:
> Hi Ticker,
>
> problem is in these lines:
> if (remove) {
> // check if the polygon contains the
> complete bounding box
> if
> (w.getBounds().contains(tileArea.getBounds())) {
> remove = false;
> }
> }
> 1) The SeaGenerator creates an outer way which is larger than the
> tile bounds.
> 2) This test was wrong because w.getBounds() returns a bbox in
> highprec values and tileArea.getBounds() is in Garmin units
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 11:00:49
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> Good.
>
> Ticker
>
> On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > attached is the patch I've created with help of svn.
> > It only reverts the changes made to MultiPolygonRelation in r3771.
> >
> > I don't know yet why they cause trouble.
> >
> > Gerd
> > ________
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Freitag, 17. Februar 2017 10:32:11
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Gerd
> >
> > Yes - if that fixes it.
> > But
> > in r3771 were there a couple of other changes not to
> > MultiPolygon...
> > haven't a lot more changes been made since to MultiPolygon...
> >
> > Ticker
> >
> >
> > On Fri, 2017-02-17 at 09:19 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > I think the problems were introduced with the highprec changes in
> > > MultiPolygonRelation in r3771.
> > > When I revert those the problem is gone. If you don't mind I
> > > commit
> > > this revert.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Gerd Petermann
> > > Gesendet: Freitag, 17. Februar 2017 10:02:38
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Ticker,
> > >
> > > don't need test data, found out what you meant.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Gerd Petermann
> > > Gesendet: Freitag, 17. Februar 2017 09:52:56
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Ticker,
> > >
> > > okay, I'll merge the branch into trunk.
> > > Please post some test data to show the coastline problem and I'll
> > > try
> > > to fix it.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Ticker Berkin
> > > Gesendet: Freitag, 17. Februar 2017 09:50:17
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Gerd
> > >
> > > I fixed this problem with r3807 in the split-shape branch and
> > > this
> > > should probably be merged into trunk.
> > >
> > > Mike was also getting another problem that might be related to
> > > generate-sea:extend-sea-sectors
> > >
> > > I don't know much about this area, but just having this option
> > > and
> > > nothing else of significance, it seems as if the overview map has
> &
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - sorry, my fault.
I've just tested a fix to this and the sea is OK now. Is is worth
keeping the high-res changes in the split-shape branch pending more
work on MultiPolygonRelation? If so I'll commit.
Ticker
On Fri, 2017-02-17 at 10:49 +, Gerd Petermann wrote:
> Hi Ticker,
>
> problem is in these lines:
> if (remove) {
> // check if the polygon contains the
> complete bounding box
> if
> (w.getBounds().contains(tileArea.getBounds())) {
> remove = false;
> }
> }
> 1) The SeaGenerator creates an outer way which is larger than the
> tile bounds.
> 2) This test was wrong because w.getBounds() returns a bbox in
> highprec values and tileArea.getBounds() is in Garmin units
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 11:00:49
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> Good.
>
> Ticker
>
> On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > attached is the patch I've created with help of svn.
> > It only reverts the changes made to MultiPolygonRelation in r3771.
> >
> > I don't know yet why they cause trouble.
> >
> > Gerd
> > ________
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Freitag, 17. Februar 2017 10:32:11
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Gerd
> >
> > Yes - if that fixes it.
> > But
> > in r3771 were there a couple of other changes not to
> > MultiPolygon...
> > haven't a lot more changes been made since to MultiPolygon...
> >
> > Ticker
> >
> >
> > On Fri, 2017-02-17 at 09:19 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > I think the problems were introduced with the highprec changes in
> > > MultiPolygonRelation in r3771.
> > > When I revert those the problem is gone. If you don't mind I
> > > commit
> > > this revert.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Gerd Petermann
> > > Gesendet: Freitag, 17. Februar 2017 10:02:38
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Ticker,
> > >
> > > don't need test data, found out what you meant.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Gerd Petermann
> > > Gesendet: Freitag, 17. Februar 2017 09:52:56
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Ticker,
> > >
> > > okay, I'll merge the branch into trunk.
> > > Please post some test data to show the coastline problem and I'll
> > > try
> > > to fix it.
> > >
> > > Gerd
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Ticker Berkin
> > > Gesendet: Freitag, 17. Februar 2017 09:50:17
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Gerd
> > >
> > > I fixed this problem with r3807 in the split-shape branch and
> > > this
> > > should probably be merged into trunk.
> > >
> > > Mike was also getting another problem that might be related to
> > > generate-sea:extend-sea-sectors
> > >
> > > I don't know much about this area, but just having this option
> > > and
> > > nothing else of significance, it seems as if the overview map has
> > > all
> > > sea if it has a coastline
> > >
> > > Ticker
> > >
> > > On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > In case you need test data: I've uploaded a file
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
problem is in these lines:
if (remove) {
// check if the polygon contains the complete
bounding box
if
(w.getBounds().contains(tileArea.getBounds())) {
remove = false;
}
}
1) The SeaGenerator creates an outer way which is larger than the tile bounds.
2) This test was wrong because w.getBounds() returns a bbox in highprec values
and tileArea.getBounds() is in Garmin units
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 11:00:49
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Good.
Ticker
On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote:
> Hi Ticker,
>
> attached is the patch I've created with help of svn.
> It only reverts the changes made to MultiPolygonRelation in r3771.
>
> I don't know yet why they cause trouble.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 10:32:11
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> Yes - if that fixes it.
> But
> in r3771 were there a couple of other changes not to MultiPolygon...
> haven't a lot more changes been made since to MultiPolygon...
>
> Ticker
>
>
> On Fri, 2017-02-17 at 09:19 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I think the problems were introduced with the highprec changes in
> > MultiPolygonRelation in r3771.
> > When I revert those the problem is gone. If you don't mind I commit
> > this revert.
> >
> > Gerd
> >
> > Von: mkgmap-dev im Auftrag
> > von Gerd Petermann
> > Gesendet: Freitag, 17. Februar 2017 10:02:38
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Ticker,
> >
> > don't need test data, found out what you meant.
> >
> > Gerd
> > ________
> > Von: mkgmap-dev im Auftrag
> > von Gerd Petermann
> > Gesendet: Freitag, 17. Februar 2017 09:52:56
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Ticker,
> >
> > okay, I'll merge the branch into trunk.
> > Please post some test data to show the coastline problem and I'll
> > try
> > to fix it.
> >
> > Gerd
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Freitag, 17. Februar 2017 09:50:17
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Gerd
> >
> > I fixed this problem with r3807 in the split-shape branch and this
> > should probably be merged into trunk.
> >
> > Mike was also getting another problem that might be related to
> > generate-sea:extend-sea-sectors
> >
> > I don't know much about this area, but just having this option and
> > nothing else of significance, it seems as if the overview map has
> > all
> > sea if it has a coastline
> >
> > Ticker
> >
> > On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > In case you need test data: I've uploaded a file :
> > > http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> > > Produces the error with r3811 without any options, just
> > > java -jar mkpgmap.jar 88009211.osm.pbf
> > > Seems to work okay with r3807.
> > >
> > > Gerd
> > >
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Mike Baggaley
> > > Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > HI Ticker, I'll package up some data for you. I have generate
> > > -sea:extend-sea-sectors in my options file, I think it will be
> > > related to that.
> > >
> > > Regards,
> > > Mike
> > >
> > > -Original Message-
> > > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > &g
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd Good. Ticker On Fri, 2017-02-17 at 09:41 +, Gerd Petermann wrote: > Hi Ticker, > > attached is the patch I've created with help of svn. > It only reverts the changes made to MultiPolygonRelation in r3771. > > I don't know yet why they cause trouble. > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 17. Februar 2017 10:32:11 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > Hi Gerd > > Yes - if that fixes it. > But > in r3771 were there a couple of other changes not to MultiPolygon... > haven't a lot more changes been made since to MultiPolygon... > > Ticker > > > On Fri, 2017-02-17 at 09:19 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I think the problems were introduced with the highprec changes in > > MultiPolygonRelation in r3771. > > When I revert those the problem is gone. If you don't mind I commit > > this revert. > > > > Gerd > > > > Von: mkgmap-dev im Auftrag > > von Gerd Petermann > > Gesendet: Freitag, 17. Februar 2017 10:02:38 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > > > Hi Ticker, > > > > don't need test data, found out what you meant. > > > > Gerd > > ________ > > Von: mkgmap-dev im Auftrag > > von Gerd Petermann > > Gesendet: Freitag, 17. Februar 2017 09:52:56 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > > > Hi Ticker, > > > > okay, I'll merge the branch into trunk. > > Please post some test data to show the coastline problem and I'll > > try > > to fix it. > > > > Gerd > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Freitag, 17. Februar 2017 09:50:17 > > An: mkgmap-dev@lists.mkgmap.org.uk > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > > > Hi Gerd > > > > I fixed this problem with r3807 in the split-shape branch and this > > should probably be merged into trunk. > > > > Mike was also getting another problem that might be related to > > generate-sea:extend-sea-sectors > > > > I don't know much about this area, but just having this option and > > nothing else of significance, it seems as if the overview map has > > all > > sea if it has a coastline > > > > Ticker > > > > On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > In case you need test data: I've uploaded a file : > > > http://files.mkgmap.org.uk/download/334/88009211.osm.pbf > > > Produces the error with r3811 without any options, just > > > java -jar mkpgmap.jar 88009211.osm.pbf > > > Seems to work okay with r3807. > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev im > > > Auftrag > > > von Mike Baggaley > > > Gesendet: Donnerstag, 16. Februar 2017 10:40:55 > > > An: mkgmap-dev@lists.mkgmap.org.uk > > > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape > > > branch > > > > > > HI Ticker, I'll package up some data for you. I have generate > > > -sea:extend-sea-sectors in my options file, I think it will be > > > related to that. > > > > > > Regards, > > > Mike > > > > > > -Original Message- > > > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] > > > Sent: 16 February 2017 08:17 > > > To: mkgmap-dev@lists.mkgmap.org.uk > > > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape > > > branch > > > > > > Hi Mike > > > > > > I'll fix/improve the message. > > > > > > Can you tell if it is the sea polygons, the line 'coastline', or > > > the > > > island area (if your style generates this) that is corrupt. > > > > > > Maybe send your splitter options / areas.list, mkgmap options and > > > style > > > and I'll see if I can reproduce. > > > > > > Ticker > > > > &
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
attached is the patch I've created with help of svn.
It only reverts the changes made to MultiPolygonRelation in r3771.
I don't know yet why they cause trouble.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 10:32:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it.
But
in r3771 were there a couple of other changes not to MultiPolygon...
haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think the problems were introduced with the highprec changes in
> MultiPolygonRelation in r3771.
> When I revert those the problem is gone. If you don't mind I commit
> this revert.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 17. Februar 2017 10:02:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Ticker,
>
> don't need test data, found out what you meant.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 17. Februar 2017 09:52:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Ticker,
>
> okay, I'll merge the branch into trunk.
> Please post some test data to show the coastline problem and I'll try
> to fix it.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 09:50:17
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> I fixed this problem with r3807 in the split-shape branch and this
> should probably be merged into trunk.
>
> Mike was also getting another problem that might be related to
> generate-sea:extend-sea-sectors
>
> I don't know much about this area, but just having this option and
> nothing else of significance, it seems as if the overview map has all
> sea if it has a coastline
>
> Ticker
>
> On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > In case you need test data: I've uploaded a file :
> > http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> > Produces the error with r3811 without any options, just
> > java -jar mkpgmap.jar 88009211.osm.pbf
> > Seems to work okay with r3807.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Mike Baggaley
> > Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > HI Ticker, I'll package up some data for you. I have generate
> > -sea:extend-sea-sectors in my options file, I think it will be
> > related to that.
> >
> > Regards,
> > Mike
> >
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > Sent: 16 February 2017 08:17
> > To: mkgmap-dev@lists.mkgmap.org.uk
> > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Mike
> >
> > I'll fix/improve the message.
> >
> > Can you tell if it is the sea polygons, the line 'coastline', or
> > the
> > island area (if your style generates this) that is corrupt.
> >
> > Maybe send your splitter options / areas.list, mkgmap options and
> > style
> > and I'll see if I can reproduce.
> >
> > Ticker
> >
> > On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> > > HI Ticker, I've tried the patch without the --order-by-decreasing
> > > -area option and it does now run without crashing. However, it
> > > suffers from the same problem as I mentioned earlier when trying
> > > -
> > > -order-by-decreasing-area without the patch, in that the
> > > coastline
> > > is
> > > corrupted. I haven't yet turned on detailed logging - I can do
> > > that
> > > if it would help.
> > >
> > > I note that in MapSplitter.java there is a new line:
> > >
> > > log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> > > area.getBounds().getCenter().toOSMURL());
> > >
> > > I think this should say '
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
Yes - if that fixes it.
But
in r3771 were there a couple of other changes not to MultiPolygon...
haven't a lot more changes been made since to MultiPolygon...
Ticker
On Fri, 2017-02-17 at 09:19 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think the problems were introduced with the highprec changes in
> MultiPolygonRelation in r3771.
> When I revert those the problem is gone. If you don't mind I commit
> this revert.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 17. Februar 2017 10:02:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Ticker,
>
> don't need test data, found out what you meant.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 17. Februar 2017 09:52:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Ticker,
>
> okay, I'll merge the branch into trunk.
> Please post some test data to show the coastline problem and I'll try
> to fix it.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Februar 2017 09:50:17
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Gerd
>
> I fixed this problem with r3807 in the split-shape branch and this
> should probably be merged into trunk.
>
> Mike was also getting another problem that might be related to
> generate-sea:extend-sea-sectors
>
> I don't know much about this area, but just having this option and
> nothing else of significance, it seems as if the overview map has all
> sea if it has a coastline
>
> Ticker
>
> On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > In case you need test data: I've uploaded a file :
> > http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> > Produces the error with r3811 without any options, just
> > java -jar mkpgmap.jar 88009211.osm.pbf
> > Seems to work okay with r3807.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Mike Baggaley
> > Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > HI Ticker, I'll package up some data for you. I have generate
> > -sea:extend-sea-sectors in my options file, I think it will be
> > related to that.
> >
> > Regards,
> > Mike
> >
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > Sent: 16 February 2017 08:17
> > To: mkgmap-dev@lists.mkgmap.org.uk
> > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Mike
> >
> > I'll fix/improve the message.
> >
> > Can you tell if it is the sea polygons, the line 'coastline', or
> > the
> > island area (if your style generates this) that is corrupt.
> >
> > Maybe send your splitter options / areas.list, mkgmap options and
> > style
> > and I'll see if I can reproduce.
> >
> > Ticker
> >
> > On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> > > HI Ticker, I've tried the patch without the --order-by-decreasing
> > > -area option and it does now run without crashing. However, it
> > > suffers from the same problem as I mentioned earlier when trying
> > > -
> > > -order-by-decreasing-area without the patch, in that the
> > > coastline
> > > is
> > > corrupted. I haven't yet turned on detailed logging - I can do
> > > that
> > > if it would help.
> > >
> > > I note that in MapSplitter.java there is a new line:
> > >
> > > log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> > > area.getBounds().getCenter().toOSMURL());
> > >
> > > I think this should say 'than' rather than 'that' and probably
> > > WANTED_MAX_AREA_SIZE should be outside the string so we see an
> > > actual
> > > number.
> > >
> > > Regards,
> > > Mike
> >
> >
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
&g
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
I think the problems were introduced with the highprec changes in
MultiPolygonRelation in r3771.
When I revert those the problem is gone. If you don't mind I commit this revert.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 17. Februar 2017 10:02:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 17. Februar 2017 09:52:56
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk.
Please post some test data to show the coastline problem and I'll try to fix it.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 09:50:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this
should probably be merged into trunk.
Mike was also getting another problem that might be related to
generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and
nothing else of significance, it seems as if the overview map has all
sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> In case you need test data: I've uploaded a file :
> http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> Produces the error with r3811 without any options, just
> java -jar mkpgmap.jar 88009211.osm.pbf
> Seems to work okay with r3807.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> HI Ticker, I'll package up some data for you. I have generate
> -sea:extend-sea-sectors in my options file, I think it will be
> related to that.
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 16 February 2017 08:17
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Mike
>
> I'll fix/improve the message.
>
> Can you tell if it is the sea polygons, the line 'coastline', or the
> island area (if your style generates this) that is corrupt.
>
> Maybe send your splitter options / areas.list, mkgmap options and
> style
> and I'll see if I can reproduce.
>
> Ticker
>
> On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> > HI Ticker, I've tried the patch without the --order-by-decreasing
> > -area option and it does now run without crashing. However, it
> > suffers from the same problem as I mentioned earlier when trying -
> > -order-by-decreasing-area without the patch, in that the coastline
> > is
> > corrupted. I haven't yet turned on detailed logging - I can do that
> > if it would help.
> >
> > I note that in MapSplitter.java there is a new line:
> >
> > log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> > area.getBounds().getCenter().toOSMURL());
> >
> > I think this should say 'than' rather than 'that' and probably
> > WANTED_MAX_AREA_SIZE should be outside the string so we see an
> > actual
> > number.
> >
> > Regards,
> > Mike
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
don't need test data, found out what you meant.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 17. Februar 2017 09:52:56
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk.
Please post some test data to show the coastline problem and I'll try to fix it.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 09:50:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this
should probably be merged into trunk.
Mike was also getting another problem that might be related to
generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and
nothing else of significance, it seems as if the overview map has all
sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> In case you need test data: I've uploaded a file :
> http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> Produces the error with r3811 without any options, just
> java -jar mkpgmap.jar 88009211.osm.pbf
> Seems to work okay with r3807.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> HI Ticker, I'll package up some data for you. I have generate
> -sea:extend-sea-sectors in my options file, I think it will be
> related to that.
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 16 February 2017 08:17
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Mike
>
> I'll fix/improve the message.
>
> Can you tell if it is the sea polygons, the line 'coastline', or the
> island area (if your style generates this) that is corrupt.
>
> Maybe send your splitter options / areas.list, mkgmap options and
> style
> and I'll see if I can reproduce.
>
> Ticker
>
> On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> > HI Ticker, I've tried the patch without the --order-by-decreasing
> > -area option and it does now run without crashing. However, it
> > suffers from the same problem as I mentioned earlier when trying -
> > -order-by-decreasing-area without the patch, in that the coastline
> > is
> > corrupted. I haven't yet turned on detailed logging - I can do that
> > if it would help.
> >
> > I note that in MapSplitter.java there is a new line:
> >
> > log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> > area.getBounds().getCenter().toOSMURL());
> >
> > I think this should say 'than' rather than 'that' and probably
> > WANTED_MAX_AREA_SIZE should be outside the string so we see an
> > actual
> > number.
> >
> > Regards,
> > Mike
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
okay, I'll merge the branch into trunk.
Please post some test data to show the coastline problem and I'll try to fix it.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 17. Februar 2017 09:50:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this
should probably be merged into trunk.
Mike was also getting another problem that might be related to
generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and
nothing else of significance, it seems as if the overview map has all
sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> In case you need test data: I've uploaded a file :
> http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> Produces the error with r3811 without any options, just
> java -jar mkpgmap.jar 88009211.osm.pbf
> Seems to work okay with r3807.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> HI Ticker, I'll package up some data for you. I have generate
> -sea:extend-sea-sectors in my options file, I think it will be
> related to that.
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 16 February 2017 08:17
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Mike
>
> I'll fix/improve the message.
>
> Can you tell if it is the sea polygons, the line 'coastline', or the
> island area (if your style generates this) that is corrupt.
>
> Maybe send your splitter options / areas.list, mkgmap options and
> style
> and I'll see if I can reproduce.
>
> Ticker
>
> On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> > HI Ticker, I've tried the patch without the --order-by-decreasing
> > -area option and it does now run without crashing. However, it
> > suffers from the same problem as I mentioned earlier when trying -
> > -order-by-decreasing-area without the patch, in that the coastline
> > is
> > corrupted. I haven't yet turned on detailed logging - I can do that
> > if it would help.
> >
> > I note that in MapSplitter.java there is a new line:
> >
> > log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> > area.getBounds().getCenter().toOSMURL());
> >
> > I think this should say 'than' rather than 'that' and probably
> > WANTED_MAX_AREA_SIZE should be outside the string so we see an
> > actual
> > number.
> >
> > Regards,
> > Mike
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd
I fixed this problem with r3807 in the split-shape branch and this
should probably be merged into trunk.
Mike was also getting another problem that might be related to
generate-sea:extend-sea-sectors
I don't know much about this area, but just having this option and
nothing else of significance, it seems as if the overview map has all
sea if it has a coastline
Ticker
On Thu, 2017-02-16 at 20:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> In case you need test data: I've uploaded a file :
> http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
> Produces the error with r3811 without any options, just
> java -jar mkpgmap.jar 88009211.osm.pbf
> Seems to work okay with r3807.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Donnerstag, 16. Februar 2017 10:40:55
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> HI Ticker, I'll package up some data for you. I have generate
> -sea:extend-sea-sectors in my options file, I think it will be
> related to that.
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 16 February 2017 08:17
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Mike
>
> I'll fix/improve the message.
>
> Can you tell if it is the sea polygons, the line 'coastline', or the
> island area (if your style generates this) that is corrupt.
>
> Maybe send your splitter options / areas.list, mkgmap options and
> style
> and I'll see if I can reproduce.
>
> Ticker
>
> On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> > HI Ticker, I've tried the patch without the --order-by-decreasing
> > -area option and it does now run without crashing. However, it
> > suffers from the same problem as I mentioned earlier when trying -
> > -order-by-decreasing-area without the patch, in that the coastline
> > is
> > corrupted. I haven't yet turned on detailed logging - I can do that
> > if it would help.
> >
> > I note that in MapSplitter.java there is a new line:
> >
> > log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> > area.getBounds().getCenter().toOSMURL());
> >
> > I think this should say 'than' rather than 'that' and probably
> > WANTED_MAX_AREA_SIZE should be outside the string so we see an
> > actual
> > number.
> >
> > Regards,
> > Mike
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Ticker,
In case you need test data: I've uploaded a file :
http://files.mkgmap.org.uk/download/334/88009211.osm.pbf
Produces the error with r3811 without any options, just
java -jar mkpgmap.jar 88009211.osm.pbf
Seems to work okay with r3807.
Gerd
Von: mkgmap-dev im Auftrag von Mike
Baggaley
Gesendet: Donnerstag, 16. Februar 2017 10:40:55
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have
generate-sea:extend-sea-sectors in my options file, I think it will be related
to that.
Regards,
Mike
-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 16 February 2017 08:17
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the
island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style
and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> HI Ticker, I've tried the patch without the --order-by-decreasing
> -area option and it does now run without crashing. However, it
> suffers from the same problem as I mentioned earlier when trying -
> -order-by-decreasing-area without the patch, in that the coastline is
> corrupted. I haven't yet turned on detailed logging - I can do that
> if it would help.
>
> I note that in MapSplitter.java there is a new line:
>
> log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> area.getBounds().getCenter().toOSMURL());
>
> I think this should say 'than' rather than 'that' and probably
> WANTED_MAX_AREA_SIZE should be outside the string so we see an actual
> number.
>
> Regards,
> Mike
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I'll package up some data for you. I have
generate-sea:extend-sea-sectors in my options file, I think it will be related
to that.
Regards,
Mike
-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 16 February 2017 08:17
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the
island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style
and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> HI Ticker, I've tried the patch without the --order-by-decreasing
> -area option and it does now run without crashing. However, it
> suffers from the same problem as I mentioned earlier when trying -
> -order-by-decreasing-area without the patch, in that the coastline is
> corrupted. I haven't yet turned on detailed logging - I can do that
> if it would help.
>
> I note that in MapSplitter.java there is a new line:
>
> log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> area.getBounds().getCenter().toOSMURL());
>
> I think this should say 'than' rather than 'that' and probably
> WANTED_MAX_AREA_SIZE should be outside the string so we see an actual
> number.
>
> Regards,
> Mike
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I'll fix/improve the message.
Can you tell if it is the sea polygons, the line 'coastline', or the
island area (if your style generates this) that is corrupt.
Maybe send your splitter options / areas.list, mkgmap options and style
and I'll see if I can reproduce.
Ticker
On Thu, 2017-02-16 at 01:23 +, Mike Baggaley wrote:
> HI Ticker, I've tried the patch without the --order-by-decreasing
> -area option and it does now run without crashing. However, it
> suffers from the same problem as I mentioned earlier when trying -
> -order-by-decreasing-area without the patch, in that the coastline is
> corrupted. I haven't yet turned on detailed logging - I can do that
> if it would help.
>
> I note that in MapSplitter.java there is a new line:
>
> log.info("Single item larger that WANTED_MAX_AREA_SIZE",
> area.getBounds().getCenter().toOSMURL());
>
> I think this should say 'than' rather than 'that' and probably
> WANTED_MAX_AREA_SIZE should be outside the string so we see an actual
> number.
>
> Regards,
> Mike
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
HI Ticker, I've tried the patch without the --order-by-decreasing-area option
and it does now run without crashing. However, it suffers from the same problem
as I mentioned earlier when trying --order-by-decreasing-area without the
patch, in that the coastline is corrupted. I haven't yet turned on detailed
logging - I can do that if it would help.
I note that in MapSplitter.java there is a new line:
log.info("Single item larger that WANTED_MAX_AREA_SIZE",
area.getBounds().getCenter().toOSMURL());
I think this should say 'than' rather than 'that' and probably
WANTED_MAX_AREA_SIZE should be outside the string so we see an actual number.
Regards,
Mike
-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 15 February 2017 16:14
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd / Mike
I've just committed a fix for this to the split-shape branch
Ticker
On Wed, 2017-02-15 at 08:53 +, Ticker Berkin wrote:
> Hi Mike
>
> OK - I think I understand the problem.
>
> Can you try with --order-by-decreasing-area and let me know if that
> stops the unbound recursion, and, in the meantime, I'll work on it.
>
> Thanks
> Ticker
>
>
> On Wed, 2017-02-15 at 00:48 +, Mike Baggaley wrote:
> > HI Ticker, having run this under the debugger now, it appears that
> > it
> > is not the postcode data after all - I was getting confused between
> > the too small to split messages and too many POIs messages. I was
> > previously getting too small to split messages in splitter, but not
> > in mkgmap.
> >
> > I temporarily changed the code to:
> >
> > } else if (mustSplit) { // can't reduce
> > size, so force more subdivisions
> > if (depth < 1000) {
> > log.debug("splitting
> > area by contents", area);
> > MapArea[] sublist =
> > area.split(1, 1, bounds, true);
> > addAreasToList(sublist,
> > alist, depth + 1);
> > continue;
> > } else {
> > log.error("Area too
> > small to split at " + area.getBounds().getCenter().toOSMURL() + "
> > (reduce the density of points, length of lines, etc.)");
> >
> > }
> > }
> >
> > This ran successfully and gave a single error:
> > Area too small to split at
> > http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17
> > (r
> > educe the density of points, length of lines, etc.
> >
> > Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND]
> > is
> > 68076 and from the coordinate it is processing the coastline. The
> > call stack has the same value for the sizes[MapArea.SHAPE_KIND] in
> > every instance of addAreasToList, so it looks like the call to
> > area.split is not actually splitting. Looking at the resulting file
> > in BaseCamp, I can see that the coastline is corrupt.
> >
> > Hope that helps,
> > Mike
> >
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > Sent: 14 February 2017 23:21
> > To: Mike Baggaley
> > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Mike
> >
> > I have the raw postcode data (codePointOpen.zip) which I processes
> > just
> > to take the first few at the same point but I can change it do all
> > of
> > them individually. Do you feed it with a map through the splitter
> > or
> > just make a postcode only overlay? What is the bit of style you use
> > to
> > represent each postcode? I can probably knock up something similar.
> >
> > The code should cope - I can't see anything obviously wrong so need
> > to
> > try and reproduce the problem
> >
> > Ticker
> >
> > On Tue, 2017-02-14 at 18:17 +, Mike Baggaley wrote:
> > > Hi Ticker the data is postcode centres (points). As well as
> > > geographic postcodes, the Royal Mail postcode data includes a
> > > number
> > > of postcodes that are centred on sorting offices (presumably for
> > > box
> > > numbers). There are quite a few at large sorting offices, but if
> > > each
> &g
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike I think this is just a problem with the rules the tool you are using to show the image conflicting with what --order-by-decreasing-area aims to achieve on a Garmin device. For instance, observations of GPSMapEdit shows it renders smaller polygons on top of larger ones as the way of deciding what is shown. --order-by-decreasing-area has split polygons geographical and so this size-based rule becomes meaningless and can result in what you are seeing. Given it didn't crash, I hope I've understood what your original problem was and fixed it in split-shape branch. Regards Ticker On Wed, 2017-02-15 at 17:12 +, Mike Baggaley wrote: > Hi Ticker, that stops the unbound recursion, however the map it > produces is faulty. The only areas that show up as land are complete > rectangles within the mainland (see attachment). Even small islets do > not have any land area. Of course this may be a different problem. > > Regards, > Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Gerd / Mike
I've just committed a fix for this to the split-shape branch
Ticker
On Wed, 2017-02-15 at 08:53 +, Ticker Berkin wrote:
> Hi Mike
>
> OK - I think I understand the problem.
>
> Can you try with --order-by-decreasing-area and let me know if that
> stops the unbound recursion, and, in the meantime, I'll work on it.
>
> Thanks
> Ticker
>
>
> On Wed, 2017-02-15 at 00:48 +, Mike Baggaley wrote:
> > HI Ticker, having run this under the debugger now, it appears that
> > it
> > is not the postcode data after all - I was getting confused between
> > the too small to split messages and too many POIs messages. I was
> > previously getting too small to split messages in splitter, but not
> > in mkgmap.
> >
> > I temporarily changed the code to:
> >
> > } else if (mustSplit) { // can't reduce
> > size, so force more subdivisions
> > if (depth < 1000) {
> > log.debug("splitting
> > area by contents", area);
> > MapArea[] sublist =
> > area.split(1, 1, bounds, true);
> > addAreasToList(sublist,
> > alist, depth + 1);
> > continue;
> > } else {
> > log.error("Area too
> > small to split at " + area.getBounds().getCenter().toOSMURL() + "
> > (reduce the density of points, length of lines, etc.)");
> >
> > }
> > }
> >
> > This ran successfully and gave a single error:
> > Area too small to split at
> > http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17
> > (r
> > educe the density of points, length of lines, etc.
> >
> > Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND]
> > is
> > 68076 and from the coordinate it is processing the coastline. The
> > call stack has the same value for the sizes[MapArea.SHAPE_KIND] in
> > every instance of addAreasToList, so it looks like the call to
> > area.split is not actually splitting. Looking at the resulting file
> > in BaseCamp, I can see that the coastline is corrupt.
> >
> > Hope that helps,
> > Mike
> >
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > Sent: 14 February 2017 23:21
> > To: Mike Baggaley
> > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Mike
> >
> > I have the raw postcode data (codePointOpen.zip) which I processes
> > just
> > to take the first few at the same point but I can change it do all
> > of
> > them individually. Do you feed it with a map through the splitter
> > or
> > just make a postcode only overlay? What is the bit of style you use
> > to
> > represent each postcode? I can probably knock up something similar.
> >
> > The code should cope - I can't see anything obviously wrong so need
> > to
> > try and reproduce the problem
> >
> > Ticker
> >
> > On Tue, 2017-02-14 at 18:17 +, Mike Baggaley wrote:
> > > Hi Ticker the data is postcode centres (points). As well as
> > > geographic postcodes, the Royal Mail postcode data includes a
> > > number
> > > of postcodes that are centred on sorting offices (presumably for
> > > box
> > > numbers). There are quite a few at large sorting offices, but if
> > > each
> > > split should be able to accept 255 points, and it is exceeding
> > > 2000
> > > splits before crashing, it looks like the splitting is not
> > > working
> > > -
> > > there won't be more than 2000 * 255 postcodes at the same place.
> > > My
> > > OSM file is rather large. I can see whether I can extract a map
> > > centred on a sorting office.
> > >
> > > Regards,
> > > Mike
> > >
> > > -Original Message-
> > > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > > Sent: 14 February 2017 17:52
> > > To: mkgmap-dev@lists.mkgmap.org.uk
> > > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape
> > > branch
> > >
> > > Hi Mike
> > >
> > > This is an
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
OK - I think I understand the problem.
Can you try with --order-by-decreasing-area and let me know if that
stops the unbound recursion, and, in the meantime, I'll work on it.
Thanks
Ticker
On Wed, 2017-02-15 at 00:48 +, Mike Baggaley wrote:
> HI Ticker, having run this under the debugger now, it appears that it
> is not the postcode data after all - I was getting confused between
> the too small to split messages and too many POIs messages. I was
> previously getting too small to split messages in splitter, but not
> in mkgmap.
>
> I temporarily changed the code to:
>
> } else if (mustSplit) { // can't reduce
> size, so force more subdivisions
> if (depth < 1000) {
> log.debug("splitting
> area by contents", area);
> MapArea[] sublist =
> area.split(1, 1, bounds, true);
> addAreasToList(sublist,
> alist, depth + 1);
> continue;
> } else {
> log.error("Area too
> small to split at " + area.getBounds().getCenter().toOSMURL() + "
> (reduce the density of points, length of lines, etc.)");
>
> }
> }
>
> This ran successfully and gave a single error:
> Area too small to split at
> http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17 (r
> educe the density of points, length of lines, etc.
>
> Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND] is
> 68076 and from the coordinate it is processing the coastline. The
> call stack has the same value for the sizes[MapArea.SHAPE_KIND] in
> every instance of addAreasToList, so it looks like the call to
> area.split is not actually splitting. Looking at the resulting file
> in BaseCamp, I can see that the coastline is corrupt.
>
> Hope that helps,
> Mike
>
> -----Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 14 February 2017 23:21
> To: Mike Baggaley
> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Mike
>
> I have the raw postcode data (codePointOpen.zip) which I processes
> just
> to take the first few at the same point but I can change it do all of
> them individually. Do you feed it with a map through the splitter or
> just make a postcode only overlay? What is the bit of style you use
> to
> represent each postcode? I can probably knock up something similar.
>
> The code should cope - I can't see anything obviously wrong so need
> to
> try and reproduce the problem
>
> Ticker
>
> On Tue, 2017-02-14 at 18:17 +, Mike Baggaley wrote:
> > Hi Ticker the data is postcode centres (points). As well as
> > geographic postcodes, the Royal Mail postcode data includes a
> > number
> > of postcodes that are centred on sorting offices (presumably for
> > box
> > numbers). There are quite a few at large sorting offices, but if
> > each
> > split should be able to accept 255 points, and it is exceeding 2000
> > splits before crashing, it looks like the splitting is not working
> > -
> > there won't be more than 2000 * 255 postcodes at the same place. My
> > OSM file is rather large. I can see whether I can extract a map
> > centred on a sorting office.
> >
> > Regards,
> > Mike
> >
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > Sent: 14 February 2017 17:52
> > To: mkgmap-dev@lists.mkgmap.org.uk
> > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
> >
> > Hi Mike
> >
> > This is an area of code I've changed and it should be able to cope
> > with
> > many items at the same location without recursing.
> >
> > Do you have some sample data? what are the items (point/line/shape
> > extended?)
> >
> > Ticker
> >
> > On Tue, 2017-02-14 at 17:40 +, Mike Baggaley wrote:
> > > Hi Gerd, since this change I am getting a
> > > java.lang.StackOverflowError crash
> > > caused by the code recursively attempting to split something
> > > which
> > > is
> > > unsplittable (assuming the split is based on location), as I have
> > > a
> > > large
> > > number of points at exactly the same location (from external data
&g
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
I have the raw postcode data (codePointOpen.zip) which I processes just
to take the first few at the same point but I can change it do all of
them individually. Do you feed it with a map through the splitter or
just make a postcode only overlay? What is the bit of style you use to
represent each postcode? I can probably knock up something similar.
The code should cope - I can't see anything obviously wrong so need to
try and reproduce the problem
Ticker
On Tue, 2017-02-14 at 18:17 +, Mike Baggaley wrote:
> Hi Ticker the data is postcode centres (points). As well as
> geographic postcodes, the Royal Mail postcode data includes a number
> of postcodes that are centred on sorting offices (presumably for box
> numbers). There are quite a few at large sorting offices, but if each
> split should be able to accept 255 points, and it is exceeding 2000
> splits before crashing, it looks like the splitting is not working -
> there won't be more than 2000 * 255 postcodes at the same place. My
> OSM file is rather large. I can see whether I can extract a map
> centred on a sorting office.
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 14 February 2017 17:52
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Mike
>
> This is an area of code I've changed and it should be able to cope
> with
> many items at the same location without recursing.
>
> Do you have some sample data? what are the items (point/line/shape
> extended?)
>
> Ticker
>
> On Tue, 2017-02-14 at 17:40 +, Mike Baggaley wrote:
> > Hi Gerd, since this change I am getting a
> > java.lang.StackOverflowError crash
> > caused by the code recursively attempting to split something which
> > is
> > unsplittable (assuming the split is based on location), as I have a
> > large
> > number of points at exactly the same location (from external data I
> > add to
> > the OSM data).
> >
> > The offending line is at
> > uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.
> > ja
> > va:187)
> > . It is failing on my system with a depth of 2342. I suggest there
> > needs to
> > be a maximum depth after which it should give up trying to split.
> >
> > } else if (mustSplit) { // can't reduce
> > size, so force more subdivisions
> > log.debug("splitting area by
> > contents", area);
> > MapArea[] sublist =
> > area.split(1, 1,
> > bounds, true);
> > addAreasToList(sublist, alist,
> > depth
> > + 1);
> > continue;
> > }
> >
> > I am unsure whether you would want a fixed depth limit, would want
> > it
> > to be
> > set by parameter, would prefer to catch the error or think it would
> > be
> > possible to see whether the proposed area split has made any
> > improvement,
> > and give up if it hasn't.
> >
> > Regards,
> > Mike
> >
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
Hi Mike
This is an area of code I've changed and it should be able to cope with
many items at the same location without recursing.
Do you have some sample data? what are the items (point/line/shape
extended?)
Ticker
On Tue, 2017-02-14 at 17:40 +, Mike Baggaley wrote:
> Hi Gerd, since this change I am getting a
> java.lang.StackOverflowError crash
> caused by the code recursively attempting to split something which is
> unsplittable (assuming the split is based on location), as I have a
> large
> number of points at exactly the same location (from external data I
> add to
> the OSM data).
>
> The offending line is at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:187)
> . It is failing on my system with a depth of 2342. I suggest there
> needs to
> be a maximum depth after which it should give up trying to split.
>
> } else if (mustSplit) { // can't reduce
> size, so force more subdivisions
> log.debug("splitting area by
> contents", area);
> MapArea[] sublist =
> area.split(1, 1,
> bounds, true);
> addAreasToList(sublist, alist,
> depth
> + 1);
> continue;
> }
>
> I am unsure whether you would want a fixed depth limit, would want it
> to be
> set by parameter, would prefer to catch the error or think it would
> be
> possible to see whether the proposed area split has made any
> improvement,
> and give up if it hasn't.
>
> Regards,
> Mike
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
