Re: [mkgmap-dev] TYP files and character encoding
Hi Gerd
I think it is best to continue with the ideas for typ-files that:
1/ they can be in any character set and we just need a better way of
working out the correct one - see my posting earlier today.
2/ it can include as many languages as anyone can be bothered to add,
and so has to be an a character set that allows the languages to be
added, implying unicode for a common one (more particulary, UTF-8)
3/ the codepage= statement should be redundant and ignored for
controlling the output character set, which should be taken from the
map, but its use for determining the input coding might need to be kept
for a while for compatability.
4/ the messages my hack generates should be turned into 1 warning or
information message per language or maybe suppressed altogether. If
someone is generating a map with a character set that doesn't support a
particular language, they really won't care that that data for other
languages that have an incompatible representation with their language
won't be there.
Ticker
On Wed, 2019-12-18 at 19:08 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think I understand now why we didn't have a default typ file ;)
> If I got that right I should revert the changes in r4395 and mkgmap
> should not allow or warn loudly when a typ file with a different
> codepage is merged?
> Or should we force the usage of unicode codepage?
> Or is it possible to compile mapnik.txt with cp 1252 (or any other)
> in a way that only those lines which contain non-matching characters
> are ignored?
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 18. Dezember 2019 19:46
> An: mkgmap development
> Betreff: [mkgmap-dev] TYP files and character encoding
>
> Hi
>
> A couple of problems with typ-files and unicode.
>
> With 'Codepage=65001' the final contents of the labels in mapnik.typ
> that is included with the composite map is unicode, but if the map is
> codepage 1252, the unicode characters with the top bit set are simply
> displayed as if in 1252.
>
> Removing the codepage statement from mapnik.txt and making fixes
> elsewhere to ensure that the file is read correctly as utf-8 and then
> generating a map with --code-page=1252, it gives the error:
>
> SEVE: uk.me.parabola.imgfmt.MapFailedException
> ../svn/trunk/resources/typ-files/mapnik.txt:
> (thrown in TypCompiler.makeMap())
> TYP file cannot be written in code page 1252
>
> Changing the exception handling in imgfmt/app/typ/TypElement.java, so
> that makeLabelBlock() reads as
> ...
> CharBuffer cb = CharBuffer.wrap(tl.getText());
> try {
> ByteBuffer buffer = encoder.encode(cb);
> out.put((byte) tl.getLang());
> out.put(buffer);
> out.put((byte) 0);
> } catch (CharacterCodingException ignore) {
> //ignore.printStackTrace();
> String name = encoder.charset().name();
> System.out.println("Cannot represent String=" +
> tl.getLang() + "," + tl.getText() +
> " in CodePage=" + name);
> //throw newTypLabelException(name);
> }
> ...
>
> It gives output like:
> Cannot represent String=21,Gara|e in CodePage=windows-1252
> Cannot represent String=21,Obszar przemysBowy in CodePage=windows
> -1252
> Cannot represent String=21,ZieleD in CodePage=windows-1252
> Cannot represent String=21,Zaro[la in CodePage=windows-1252
> Cannot represent String=21,MokradBa in CodePage=windows-1252
> Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in
> CodePage=windows-1252
> Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
> CodePage=windows-1252
> Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
> CodePage=windows-1252
> Cannot represent String=21,Zcie|ka rowerowa in CodePage=windows-1252
> Cannot represent String=21,Wybrze|e in CodePage=windows-1252
> Cannot represent String=21,Zcie|ka in CodePage=windows-1252
> Cannot represent String=21,StrumieD in CodePage=windows-1252
> Cannot represent String=21,Granica paDstwa in CodePage=windows-1252
> Cannot represent String=21,Rzeka, KanaB in CodePage=windows-1252
> Cannot represent String=21,StrumieD in CodePage=windows-1252
> Cannot represent String=21,Ruroci^Eg in CodePage=windows-1252
> Cannot represent String=21,Kabel wysokiego napi^Ycia in
> CodePage=windows-1252
> Cannot represent String=21,Tor wy[cigowy in CodePage=windows-1252
> Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
> CodePage=windows-1252
> Cannot represent String=21,Droga krajowa (B^Ecznik) in
> CodePage=windows
> -1252
> Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in
> CodePage=windows-1252
> Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252
> Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252
> Cannot represent String=21,Restauracja (AmerykaDska) in
> CodePage=windows-1252
> Cannot represent String=21,Restauracja (ChiDska) in CodePage=windows
> -1252
> Cannot re
Re: [mkgmap-dev] TYP files and character encoding
Hi Ticker,
I think I understand now why we didn't have a default typ file ;)
If I got that right I should revert the changes in r4395 and mkgmap should not
allow or warn loudly when a typ file with a different codepage is merged?
Or should we force the usage of unicode codepage?
Or is it possible to compile mapnik.txt with cp 1252 (or any other) in a way
that only those lines which contain non-matching characters are ignored?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Mittwoch, 18. Dezember 2019 19:46
An: mkgmap development
Betreff: [mkgmap-dev] TYP files and character encoding
Hi
A couple of problems with typ-files and unicode.
With 'Codepage=65001' the final contents of the labels in mapnik.typ
that is included with the composite map is unicode, but if the map is
codepage 1252, the unicode characters with the top bit set are simply
displayed as if in 1252.
Removing the codepage statement from mapnik.txt and making fixes
elsewhere to ensure that the file is read correctly as utf-8 and then
generating a map with --code-page=1252, it gives the error:
SEVE: uk.me.parabola.imgfmt.MapFailedException
../svn/trunk/resources/typ-files/mapnik.txt:
(thrown in TypCompiler.makeMap())
TYP file cannot be written in code page 1252
Changing the exception handling in imgfmt/app/typ/TypElement.java, so
that makeLabelBlock() reads as
...
CharBuffer cb = CharBuffer.wrap(tl.getText());
try {
ByteBuffer buffer = encoder.encode(cb);
out.put((byte) tl.getLang());
out.put(buffer);
out.put((byte) 0);
} catch (CharacterCodingException ignore) {
//ignore.printStackTrace();
String name = encoder.charset().name();
System.out.println("Cannot represent String=" +
tl.getLang() + "," + tl.getText() +
" in CodePage=" + name);
//throw newTypLabelException(name);
}
...
It gives output like:
Cannot represent String=21,Gara|e in CodePage=windows-1252
Cannot represent String=21,Obszar przemysBowy in CodePage=windows-1252
Cannot represent String=21,ZieleD in CodePage=windows-1252
Cannot represent String=21,Zaro[la in CodePage=windows-1252
Cannot represent String=21,MokradBa in CodePage=windows-1252
Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Zcie|ka rowerowa in CodePage=windows-1252
Cannot represent String=21,Wybrze|e in CodePage=windows-1252
Cannot represent String=21,Zcie|ka in CodePage=windows-1252
Cannot represent String=21,StrumieD in CodePage=windows-1252
Cannot represent String=21,Granica paDstwa in CodePage=windows-1252
Cannot represent String=21,Rzeka, KanaB in CodePage=windows-1252
Cannot represent String=21,StrumieD in CodePage=windows-1252
Cannot represent String=21,Ruroci^Eg in CodePage=windows-1252
Cannot represent String=21,Kabel wysokiego napi^Ycia in
CodePage=windows-1252
Cannot represent String=21,Tor wy[cigowy in CodePage=windows-1252
Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Droga krajowa (B^Ecznik) in CodePage=windows
-1252
Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252
Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252
Cannot represent String=21,Restauracja (AmerykaDska) in
CodePage=windows-1252
Cannot represent String=21,Restauracja (ChiDska) in CodePage=windows
-1252
Cannot represent String=21,Restauracja (Mi^Ydzynarodowa) in
CodePage=windows-1252
Cannot represent String=21,Restauracja (WBoska) in CodePage=windows
-1252
Cannot represent String=21,Restauracja (MeksykaDska) in
CodePage=windows-1252
Cannot represent String=21,Restauracja (P^Eczki) in CodePage=windows
-1252
Cannot represent String=21,Restauracja (WegetariaDska) in
CodePage=windows-1252
Cannot represent String=21,Kr^Ygle in CodePage=windows-1252
Cannot represent String=21,Sklep odzie|owy in CodePage=windows-1252
Cannot represent String=21,Wypo|yczalnia samochod\363w in
CodePage=windows-1252
Cannot represent String=21,Gara| in CodePage=windows-1252
Cannot represent String=21,Sprzeda| samochod\363w in CodePage=windows
-1252
Cannot represent String=21,Sklep |eglarski in CodePage=windows-1252
Cannot represent String=21,S^Ed in CodePage=windows-1252
Cannot represent String=21,O[rodek kultury in CodePage=windows-1252
Cannot represent String=21,Wi^Yzienie in CodePage=windows-1252
Cannot represent String=21,Stra| po|arna in CodePage=windows-1252
Cannot represent String=21,SBupek in CodePage=windows-1252
Cannot represent String=21,PrzystaD in CodePage=windows-1252
Cannot represent String=21,L^Edowisko helikopterowe in CodePage=windows
-1252
Cannot represent String=21,W
[mkgmap-dev] TYP files and character encoding
Hi
A couple of problems with typ-files and unicode.
With 'Codepage=65001' the final contents of the labels in mapnik.typ
that is included with the composite map is unicode, but if the map is
codepage 1252, the unicode characters with the top bit set are simply
displayed as if in 1252.
Removing the codepage statement from mapnik.txt and making fixes
elsewhere to ensure that the file is read correctly as utf-8 and then
generating a map with --code-page=1252, it gives the error:
SEVE: uk.me.parabola.imgfmt.MapFailedException
../svn/trunk/resources/typ-files/mapnik.txt:
(thrown in TypCompiler.makeMap())
TYP file cannot be written in code page 1252
Changing the exception handling in imgfmt/app/typ/TypElement.java, so
that makeLabelBlock() reads as
...
CharBuffer cb = CharBuffer.wrap(tl.getText());
try {
ByteBuffer buffer = encoder.encode(cb);
out.put((byte) tl.getLang());
out.put(buffer);
out.put((byte) 0);
} catch (CharacterCodingException ignore) {
//ignore.printStackTrace();
String name = encoder.charset().name();
System.out.println("Cannot represent String=" +
tl.getLang() + "," + tl.getText() +
" in CodePage=" + name);
//throw newTypLabelException(name);
}
...
It gives output like:
Cannot represent String=21,Gara|e in CodePage=windows-1252
Cannot represent String=21,Obszar przemysBowy in CodePage=windows-1252
Cannot represent String=21,ZieleD in CodePage=windows-1252
Cannot represent String=21,Zaro[la in CodePage=windows-1252
Cannot represent String=21,MokradBa in CodePage=windows-1252
Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Zcie|ka rowerowa in CodePage=windows-1252
Cannot represent String=21,Wybrze|e in CodePage=windows-1252
Cannot represent String=21,Zcie|ka in CodePage=windows-1252
Cannot represent String=21,StrumieD in CodePage=windows-1252
Cannot represent String=21,Granica paDstwa in CodePage=windows-1252
Cannot represent String=21,Rzeka, KanaB in CodePage=windows-1252
Cannot represent String=21,StrumieD in CodePage=windows-1252
Cannot represent String=21,Ruroci^Eg in CodePage=windows-1252
Cannot represent String=21,Kabel wysokiego napi^Ycia in
CodePage=windows-1252
Cannot represent String=21,Tor wy[cigowy in CodePage=windows-1252
Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Droga krajowa (B^Ecznik) in CodePage=windows
-1252
Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in
CodePage=windows-1252
Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252
Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252
Cannot represent String=21,Restauracja (AmerykaDska) in
CodePage=windows-1252
Cannot represent String=21,Restauracja (ChiDska) in CodePage=windows
-1252
Cannot represent String=21,Restauracja (Mi^Ydzynarodowa) in
CodePage=windows-1252
Cannot represent String=21,Restauracja (WBoska) in CodePage=windows
-1252
Cannot represent String=21,Restauracja (MeksykaDska) in
CodePage=windows-1252
Cannot represent String=21,Restauracja (P^Eczki) in CodePage=windows
-1252
Cannot represent String=21,Restauracja (WegetariaDska) in
CodePage=windows-1252
Cannot represent String=21,Kr^Ygle in CodePage=windows-1252
Cannot represent String=21,Sklep odzie|owy in CodePage=windows-1252
Cannot represent String=21,Wypo|yczalnia samochod\363w in
CodePage=windows-1252
Cannot represent String=21,Gara| in CodePage=windows-1252
Cannot represent String=21,Sprzeda| samochod\363w in CodePage=windows
-1252
Cannot represent String=21,Sklep |eglarski in CodePage=windows-1252
Cannot represent String=21,S^Ed in CodePage=windows-1252
Cannot represent String=21,O[rodek kultury in CodePage=windows-1252
Cannot represent String=21,Wi^Yzienie in CodePage=windows-1252
Cannot represent String=21,Stra| po|arna in CodePage=windows-1252
Cannot represent String=21,SBupek in CodePage=windows-1252
Cannot represent String=21,PrzystaD in CodePage=windows-1252
Cannot represent String=21,L^Edowisko helikopterowe in CodePage=windows
-1252
Cannot represent String=21,Wie|a in CodePage=windows-1252
Cannot represent String=21,yr\363dBo in CodePage=windows-1252
Cannot represent String=21,Pla|a in CodePage=windows-1252
Cannot represent String=21,Przyl^Edek in CodePage=windows-1252
Cannot represent String=21,SkaBa in CodePage=windows-1252
Which makes sense if codepage 1252 doesn't handle Polish (hex 0x15,
decimal 21).
NB the non ascii characters in above are messed up by my cutting and pasting.
Checking the French, on my Garmin device, the type descriptions now display
accents correctly.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http:/
[mkgmap-dev] yearly summary of mkgmap changes ?
Another year of incredible development of mkgmap. Thanks! It would be helpful to have a yearly summary of the major mkgmap changes as there are too many for me to keep track of by following the dev-digest (although this is very helpful). Items such as new options, option changes/updates, code/behaviour changes, depreciated options are things that spring to mind. My concern is that following the dev-digest is following the trees and I may have missed the big picture. In addition, changes/updates that are planned during the next year would be helpful and maybe users could be polled for their top 3, although I have not had much success when polling my users. An option to not compress splitter file output is still top 'o my list. ; The wiki may be a good place for this list rather than buried in the dev-digest. I would offer to help with this but head off to Chile for 3 months of needed hiking, using maps made with mkgmap (of course) and will be without net connection. I am happy to review but leave in 2 weeks. Thanks, -- pitney - end of message ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New branch for default typ file
Hi Randolph
This topic should probably become a new thread.
You shouldn't confuse the encoding of the java source text (rules
determined by the java language) with how a java program reads a text
file into its internal character format (however the programmers want
to do it, but the java library supplies converters for almost all
character sets/encodings).
I agree that the text file input processing of mkgmap should allow for
a BOM in all cases and use it to determine the correct unicode input
decoding. There are various possible input files with a mix of
character set/encoding determination and BOM acceptance.
A quick look for the the various txt inputs, I find:
style components: In the default style, all are pure 7-bit ascii.
except inc/address which contains some UTF-8 encoded characters.
road-name-config: this is read as UTF-8.
TYP: This checks for a UFT-8 BOM as the first character on a line, and,
if not there, looks for a line starting with 'CodePage=' and uses what
follows, with cp65001 taken to mean UTF-8. It has some logic to default
to cp1252 and some other convolutions.
There are many incorrect assumptions in this handling, the main one
being that CodePage is there to determine the output charset, which can
be determined from the main mkgmap map options anyway.
-c options.cfg: I haven't studied the logic for this, but it probably
uses the character set/encoding determined by Java from the
environment; on unix maybe $LANG with typical value "en_GB.UTF-8"
command line parameters: ditto
copyright/licence-file: not looked
delete-tags-file: not looked
other files: ?
Most of these areas could benefit from a unified way of determining the
input character set and encoding, but we need to beware of backward
compatibility, where users have their own components in a code-page
relevant to their area.
I suggest something like the following, in order:
1/ Look for a BOM for any of the unicode encodings near the start of
the file; not necessarily the first character, because, without
changing the next level of the file parser, it might need to be in a
comment.
2/ Look for the 1st or 2nd line of the format:
{comment-indicator} -*- coding: {charset} -*-
where {comment-indicator} is typically a '#'. and {charset}, for
unicode, represents the encoding as well. This method is used by Python
and was common on unix systems and recognised by many text editors
before UTF-8 became ubiquitous.
3/ Default to UTF-8 or the environmental default depending on context,
to be compatible with current handling.
Ticker
On Tue, 2019-12-17 at 15:20 -0600, Randolph J. Herber wrote:
> Dear Sirs:
> There has been a thread of discussion of whether there should be a
> Beginning Of Message (BOM) at the beginning of a UTF-8 file.
> This discussion is complicated by the fact that some of the
> developers work on Unix, Linux, BSD, iOS, Solaris and Windows. These
> operating systems have UTF-8 handling libraries written at different
> times and to different Unicode standards. Originally the Unicode
> standard said that UTF-8 should not have a BOM character at the
> beginning of a file. Later Unicode changed the standard to a BOM is
> permissible, not required and not recommended. Microsoft added a BOM
> to the beginning of UTF-8 files before doing so was permissible to
> ease the problem of recognizing a UTF-8 file. This broke the other
> operating systems' handling of UTF-8. Microsoft petitioned for the
> permissibility of a BOM to avoid changing their file handling.
> At this time, I believe at all programs should use Unicode and not
> Microsoft code pages. I have had problems with Microsoft code pages
> since MSDOS days.
> Splitter and mkgmap are written in Java. Java still follows the
> original Unicode standard of no BOM at the beginning of a UTF-8 text
> file. This is a "not to fixed" situation per the Java language
> developers. This situation results in problems with Java,
> particularly in a Microsoft Windows environment,
> The code fragments below provide Java solutions to writing a BOM at
> the beginning of a UTF-8 text files so that Microsoft native text
> editors can handle them and, on reading a text file, provides a
> automatic way of ignoring an optional BOM by checking for the BOM
> after file opening.
> A test for execution in a Windows environment is provided below if
> one decides to add a BOM only on Microsoft Windows.
> I have not downloaded the splitter and mkgmap sources and searched
> for the appropriate places in their sources to apply the changes. I
> feel the main splitter and mkgmap developers are placed better to
> make these changes. This is the reason that I did not provide patches
> to the sources.
> Randolph J. Herber.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Precomp-sea (to Ticker)
Hi David With option --add-pois-to-area, for all polygons a point is determined wich is then fed through the style 'points' rules with the additional tag mkgmap:area2poi=true. It is then up to the 'points' rules to decide what to do. The determination of the location of the points is described in the mkgmap help (mkgmap-r/doc/options.txt) So, if OSM defines a bay with a polygon, the area can be rendered with the 'polygon' rule: natural=bay & name=* [0x3d resolution 18] and, if --add-pois-to-area, a 'point' rule such as: natural=bay [0x6503 resolution 18] This rule doesn't exist in the default style, but it might to soon. If OSM defines the bay as a point, only the 'points' rule is triggered and this is regardless of the --add-pois-to-area option. Ticker On Tue, 2019-12-17 at 20:07 +0100, David wrote: > Hi, > The option « add-pois-to-areas » adds a POI to every polygons. I did > not understand well the documentation about how to select which > polygons are affected. Wouldn’t it be possible to replace selected > polygons by a POI placed at its barycentric point with a rule in a > style file ? (We can already use a polygon as a line) > Last remark, some bays are described in OSM with a POI and Garmin > format defines the corresponding symbol (0x6503). > > David > > ___ > 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] Commit r4397: implement and document new option --is-in-landuse=value[, value...]
Hi all, with r4398 I've reverted the changes from r4397. This needs much more effort to work as wanted. Even with the complete patch posted yesterday the results are only a good guess. For exact results we need very different algorithms and data structures, esp. it is not (yet) possible to find out if a node is on the boundary of a polygon. So, I think we should collect a few special cases first and try to find a common decision about the expected result. I'd try to put them into a unit test and maybe we find code that works. Gerd Von: mkgmap-dev im Auftrag von jan meisters Gesendet: Dienstag, 17. Dezember 2019 23:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...] Hi all, while testing up to r4397 with is-in I had a lot of erratic results, most of them due to overlapping or area-crossings. So - if reasonable - I opt for Tickers approach. Jan > Am 17.12.2019 um 19:39 schrieb Gerd Petermann > : > > Hi Ticker, > > I can draw two triangles A and B in such a way that they are overlapping but > no point of A is in B and no point of B is in A. > > Of course I can also draw an unclosed straight way which lies almost > completely within an area but endpoints are outside. > So, as long as we don't perform much more complex tests we just get a good > guess. > > So, for a precise result I would not want to do the calculation for all > elements just in case the style might ask for it. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Ticker Berkin > Gesendet: Dienstag, 17. Dezember 2019 18:05 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option > --is-in-landuse=value[, value...] > > Hi Gerd > > I was thinking it would be slow to do the full test and I've seen your > summary of what you've implemented and have no problem with it. > > The meaning with either being multiPolygons would be almost impossible > to define, but otherwise I'd define it as such: > > Point: if within or on edge then IN otherwise OUT. > > Way/polygons: if all points are outside or on edge, then OUT, if some > are inside and some outside then STRADDLE, otherwise, ie at least 1 > point is inside, IN > > Ticker > > On Tue, 2019-12-17 at 13:32 +, Gerd Petermann wrote: >> Hi Ticker, >> >> I agree it would be good to know. >> Problem: it would require a completely different implementation and >> probably a lot more CPU power to compute that information. >> >> The current test is very lazy, it works like the one for the >> mkgmap:admin_level tags. It computes a single point that represents >> the OSM element >> and checks if that point is within or on the boundary of any >> landuse=x polygon. I think that was OK for the original problem >> (building inside landuse=residential), >> but it was already problematic with the idea to set a maxspeed value >> for a major highway "inside" a residential area. >> >> So, what results do we get? >> - A point is either outside, inside or on the boundary of a polygon. >> - A line or polygon can be outside, inside, on the boundary or partly >> overlapping a single polygon. What would be the result for a way that >> builds a part of the boundary of two natural=wood multipolygons? What >> would be the result when the way crosses such a boundary, but is >> always inside one of the natural=wood polygons? Also, a way can be >> inside one polygon and partly inside another, as OSM allows >> overlapping polygons. >> Think of a landuse=forest multipolygon with an inner way >> natural=water . Is the inner way inside, outside or on the boundary? >> Remenber, the hook doesn't "see" the multipolygon, it processes the >> results of the MultipolygonCutter. >> >> For JOSM I've implemented some area operators like a inside b or vice >> versa, also a not inside b, but they only work on nodes and polygons, >> and they are rather slow. >> See https://josm.openstreetmap.de/ticket/10391 >> I assume you have something similar in mind? >> >> Gerd >> >> >> >> >> >> Von: Pinns UK >> Gesendet: Dienstag, 17. Dezember 2019 13:08 >> An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk >> Betreff: Re: AW: [mkgmap-dev] Commit r4397: implement and document >> new option --is-in-landuse=value[, value...] >> >> Hi Gerd >> >> That would be very useful >> >> r >> >> Nick >> >> On 17/12/2019 11:15, Gerd Petermann wrote: >>> Hi Nick, >>> >>> OK, I already expected this when I asked if landuse is enough... >>> I'll add code to support all polygons and see how to document it. I >>> guess it should be no problem when I revert the changes in r4397. >>> >>> Gerd >>> >>> >>> Von: mkgmap-dev im Auftrag >>> von Pinns UK >>> Gesendet: Dienstag, 17. Dezember 2019 11:53 >>> An: mkgmap-dev@lists.mkgmap.org.uk >>> Betreff: Re: [mkgmap-
[mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option)
Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019 revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
