giggls / mapnik-german-l10n Goto Github PK

Please switch the Thai transliteration library.

I checked this area:
https://www.openstreetmap.de/karte.html?zoom=16&lat=18.86776&lon=99.14068&layers=B000TF

For example this node:
https://www.openstreetmap.org/node/4542027125

with the Thai name:
ห้องสมุดประชาชน

is being rendered as

"ongtmutpnatatn"

The python library here:
https://pypi.org/project/tltk/

gives the much better RTGS transliteration of
hongsamut prachachon

 out = tltk.nlp.th2roman(txt)

Probably even capitalize the initial characters.

Could a variant of osml10n_translit take what source and target language is being transliterated? Currently, the implementation always calls Any-Latin. Although this works as a fallback, ICU would return better quality if you were passing the source and target language. For background, see this talk. Here’s a few examples from the unit tests in Unicode CLDR, which is the upstream source for ICU’s transliterators. The transliteration IDs are in IETF BCP 47-T (RFC 6497) syntax, such as:

• ja-t-es: Japanese, transliterated from Spanish (test cases, abanilla ⇒ アバニリャ)

• ja-t-es-419: Japanese, transliterated from Latin American Spanish (test cases, abanilla ⇒ アバニヤ)

• ka-Latn-t-ka-m0-bgn-1981: Georgian in Latin letters, transliterated from Georgian using the 1981 version of the BGN romanization (test cases, საყოველთაო ⇒ saqovelt’ao)

• ka-Latn-t-ka-m0-bgn-2009: Georgian in Latin letters, transliterated from Georgian according to the 2009 version of the BGN romanization (test cases, საყოველთაო ⇒ saqʼoveltao)

Implementation detail: With the current ICU version, you’d unfortunately have to mangle BCP47-T identifiers before creating the ICU transliterator. Future ICU versions will expose BCP47-T identifiers to outside callers, but I can’t promise when this will be deployed; there’s higher priority bugs. However, the capability to select particular transforms has always been present in ICU. This name mangling is an implementation detail which could be hidden from callers. My recommendation for osml10n_translit would be to accept an optional parameter with an IETF BCP47-T identifier; their syntax has been standardized in RFC 6497. ICU can be instructed to fall back to Any-Latin in case the requested transliterator is unavailable.

Performance: Consider caching the ICU Transform objects across invocations. In the current implementation, a new icu::Transform gets created and disposed for every transliterated label. This is actually quite expensive; it would be faster to reuse the Transforms. I don’t know whether Postgres is multi-threaded; if it is, it would be necessary to use a mutex around icu::Transform::transliterate() because the current ICU implementation is not thread-safe. (It’s perfectly safe to simultaneously call this method on different icu::Transform instances, but only one single thread at a time should call transliterate() on the same icu::Transform object). Despite the locking, it’ll be much faster to reuse Transform objects across multiple calls. No locking is needed when each thread has its private set of icu::Transform objects; this could be done by putting a std::hash_map<transliterator_id, icu::Transform*> into thread-local storage.

Sorry for not just sending you a patch to implement this change; I know nothing about Postgres internals. But for someone familiar with the codebase this should be quite an easy change, with a noticeable improvement in transliteration quality. However, do tell if you want me to write a C++ function for converting BCP 47-T syntax to ICU’s legacy identifiers; I could do that for you.

Trying to install:

# make deb
dpkg-buildpackage -b -us -uc
dpkg-buildpackage: source package osml10n
dpkg-buildpackage: source version 2.2.0
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Sven Geggus <[email protected]>
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build mapnik-german-l10n
dpkg-checkbuilddeps: Unmet build dependencies: libutf8proc-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
Makefile:44: recipe for target 'deb' failed
make: *** [deb] Error 3

However, the libutf8proc-dev is only available on testing and unstable. And cannot be installed: https://packages.debian.org/search?searchon=names&keywords=libutf8proc-dev

And make fails with

~/software/mapnik-german-l10n# make
pandoc --from markdown_github --to html --standalone INSTALL.md --output INSTALL.html
pandoc --from markdown_github --to html --standalone README.md --output README.html
pandoc --from markdown_github --to plain --standalone INSTALL.md --output INSTALL
pandoc --from markdown_github --to plain --standalone README.md --output README
make -C kanjitranscript
make[1]: Entering directory '/root/software/mapnik-german-l10n/kanjitranscript'
cc -fpic -fno-exceptions -I/usr/include/postgresql/9.4/server -c kanjitranscript.c
kanjitranscript.c:20:22: fatal error: utf8proc.h: No such file or directory
 #include <utf8proc.h>
                      ^
compilation terminated.
Makefile:13: recipe for target 'kanjitranscript.o' failed
make[1]: *** [kanjitranscript.o] Error 1
make[1]: Leaving directory '/root/software/mapnik-german-l10n/kanjitranscript'
Makefile:29: recipe for target 'kanjitranscript' failed
make: *** [kanjitranscript] Error 2

So I am searching for utf8proc.h with:

# apt-file search utf8proc.h
libxqilla-dev: /usr/include/xqilla/utils/utf8proc.h

But I doubt this is the right file.

Any ideas on how to proceed?

This is related to gravitystorm/openstreetmap-carto#3870 and someone in that issue pointed me here.

I setup my own mapping tile server according to the instructions found at https://switch2osm.org/manually-buildin … 18-04-lts/ (amazing job for whoever wrote them) and am using the planet data (https://planet.openstreetmap.org). However, when I render a tile in, for example, China (http://localhost/hot/7/106/53.png / https://a.tile.openstreetmap.org/7/106/53.png)), the labels are in Chinese characters.

As I understand it, this project can assist me in getting english only labels, but I am not exactly sure how it fits in with the rest of the system.

Is it intended to be a drop-in replacement for apt install mapnik-utils python-mapnik ?

What changes would need to be made to the instructions for setting up a tile server to integrate this project and specify English only labels?

Or, have I misunderstood something?

This is some code to convert french and english cardinal numbers to superscripts. - If you like it and it looks better on the map, just pick the code you need. If you stay with the current way no problem at all.

English:

  abbrev=regexp_replace(abbrev,'1st\M','1ˢᵗ');
  abbrev=regexp_replace(abbrev,'2nd\M','2ⁿᵈ');
  abbrev=regexp_replace(abbrev,'3rd\M','3ʳᵈ');

French:

  abbrev=regexp_replace(abbrev,'^1re\M','1ʳᵉ');
  abbrev=regexp_replace(abbrev,'(?<=^[0-9]+)e\M','ᵉ');

More characters (if needed) here:

• https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts#Latin_and_Greek_tables

First off: I'm not sure if this is really a bug or just a setup error - but you can probably spot this more quickly than I can.

On my tileserver, some tiles fail to rerender after an Update from Ubuntu 16.04 to 18.04 because they throw SQL errors like this:

Mapnik datasource exception: Postgis Plugin: ERROR:  column "osml10n_street_abbrev_ja" does not exist
#012LINE 1: select osml10n_street_abbrev_ja-Latn('Kōzai Minamimachi')
#012               ^
#012QUERY:  select osml10n_street_abbrev_ja-Latn('Kōzai Minamimachi')
#012CONTEXT:  PL/pgSQL function osml10n_street_abbrev(text,text) line 9 at EXECUTE
#012PL/pgSQL function osml10n_gen_combined_name(text,text,hstore,boolean,boolean,text,boolean,boolean,boolean) line 144 at assignment
#012PL/pgSQL function osml10n_get_name_from_tags(hstore,boolean,boolean,boolean,text,text,geometry) line 53 at RETURN
#012PL/pgSQL function osml10n_get_streetname_from_tags(hstore,boolean,boolean,text,text,geometry,text) line 7 at RETURN
#012in executeQuery Full sql was: 'SELECT ST_AsBinary("way") AS geom,"highway","junction","name","ref" FROM (SELECT
#012    way,
#012    highway,
#012    junction,
#012    ref,
#012    localized_streetname as name,
#012    NULL AS way_pixels
#012  FROM planet_osm_point_de
#012  WHERE highway = 'motorway_junction' OR highway = 'traffic_signals' OR junction = 'yes'
#012UNION ALL
#012  SELECT
#012    way,
#012    highway,
#012    junction,
#012    ref,
#012    name,
#012    way_area/NULLIF(38.2185::real*38.2185::real,0) AS way_pixels
#012  FROM planet_osm_polygon_de
#012  WHERE junction = 'yes'
#012  ORDER BY way_pixels DESC NULLS LAST
#012) AS junctions WHERE "way" && ST_SetSRID('BOX3D(14852020.34392288 3972279.485924038,14969427.61936892 4089686.761370071)'::box3d, 3857)'

(this is the metatile at x=3624 y=1624 z=12)
so it seems that somewhere in a deep callstack, localized_streetname in very rare cases internally calls osml10n_street_abbrev_ja which does not exist?
This only ever happens with osml10n_street_abbrev_ko, _sr or _ja. I see that other functions like osml10n_street_abbrev_de or _fr or _ru do exist. So should _ko/_sr/_ja exist too? If not, why is it called?

The current implementation of osml10n_get_name_without_brackets_from_tags is very slow.

Running it on all transport ways of Europe is too long, I did not let it finish, I took more than one day.

When disabling call to osml10n_geo_translit from osml10n_get_name_without_brackets_from_tags it took only around 90s.
https://github.com/giggls/mapnik-german-l10n/blob/master/plpgsql/get_localized_name_from_tags.sql#L361

osml10n_geo_translit itself call to the slow osml10n_get_country (making a spatial query)
https://github.com/giggls/mapnik-german-l10n/blob/master/plpgsql/geo_transliterate.sql#L63
https://github.com/giggls/mapnik-german-l10n/blob/master/plpgsql/get_country.sql

The country is used only when it is 'jp' or 'th'
https://github.com/giggls/mapnik-german-l10n/blob/master/plpgsql/geo_transliterate.sql#L25-L34

I think 'th' would be better detected from Thai alphabet rather than geometry location.

About 'jp' why required to be in Japan to detect if CJK are in name ?

My point of view is that the country detection can be removed.

Goal:

• Use https://github.com/gravitystorm/openstreetmap-carto
• Add the latin transliteration & abbreviation features

Question:

• Is there a simple, non-invasive way to do so?

Background:

• OSM-FR has an abbreviation hack
• OSM-CH has an abbreviation hack
• ....

It would be nice to have a simple, drop-in way to install it on a "OSMcarto" or derived map without a lot of changes to the map. Then it would be simple to promote the module and get more logic feeded in from the local communities and become the abbreviation reference source.

Any idea?

btw.:
Nominatin has an own logic (https://github.com/openstreetmap/Nominatim/blob/master/module/tokenstringreplacements.inc) too, but I will tackle this later :-)

The proposed documentation moved here, to be able to re-fork soon:

• https://github.com/chatelao/osm-documentation

I am trying to get this project installed and everything seemed to go ok until attempting create the extension.

postgres@ubuntu:~$ psql
psql (10.10 (Ubuntu 10.10-0ubuntu0.18.04.1))
Type "help" for help.

postgres=# \c gis
You are now connected to database "gis" as user "postgres".
gis=#
gis=# CREATE EXTENSION osml10n CASCADE;
NOTICE:  installing required extension "unaccent"
NOTICE:  installing required extension "fuzzystrmatch"
ERROR:  could not load library "/usr/lib/postgresql/10/lib/osml10n_translit.so": /usr/lib/postgresql/10/lib/osml10n_translit.so: undefined symbol: _ZNK6icu_6413UnicodeString7extractEPciP10UConverterR10UErrorCode

I need your opinion:

• The code below is reformated from pure SQL in "openstreetmap.fr" (https://github.com/cquest/osmfr-cartocss/blob/master/functions.sql)

Gretchen Question:

• How should we judge this code, if it is okay to be integrated?
• It is valid for french, but a few keywords may cause collateral damage as they may be used in other languages too.

--
-- Name: fr_abbrev(text); Type: FUNCTION; Schema: public; Owner: postgres
--
CREATE OR REPLACE FUNCTION fr_abbrev(longtext) RETURNS TEXT AS $$
 DECLARE
  abbrev text;
 BEGIN
    abbrev = longtext;
    abbrev = replace($abbrev,'lémentaire ','lem. ');
    abbrev = replace($abbrev, 'econdaire ','econd. ');
    abbrev = replace($abbrev, 'rimaire ','rim. ');
    abbrev = replace($abbrev, 'aternelle ','at. ');
    abbrev = replace($abbrev, 'ommerciale ','omm. ');
    abbrev = replace($abbrev, 'Direction ','Dir. ');
    abbrev = replace($abbrev, 'Chapelle ','Chap. ');
    abbrev = replace($abbrev, 'Cathédrale ','Cath. ');
    abbrev = replace($abbrev, ' Notre-Dame ',' N.D. ');

    abbrev = replace($abbrev, 'Avenue ','Av. ');
    abbrev = replace($abbrev, 'Boulevard ','Bd. ');
    abbrev = replace($abbrev, 'Esplanade ','Espl. ');
    abbrev = replace($abbrev, 'Faubourg ','Fbg. ');
    abbrev = replace($abbrev, 'Passage ','Pass. ');
    abbrev = replace($abbrev, 'Place ','Pl. ');
    abbrev = replace($abbrev, 'Promenade ','Prom. ');
    abbrev = replace($abbrev, 'Impasse ','Imp. ');

    abbrev = replace($abbrev, 'Square ','Sq. ');

    abbrev = replace($abbrev, 'Centre Commercial ','CCial. ');
    abbrev = replace($abbrev, 'Immeuble ','Imm. ');
    abbrev = replace($abbrev, 'Lotissement ','Lot. ');
    abbrev = replace($abbrev, 'Résidence ','Rés. ');
    abbrev = replace($abbrev, 'Zone Industrielle ','ZI. ');
    abbrev = replace($abbrev, 'Adjudant ','Adj. ');
    abbrev = replace($abbrev, 'Agricole ','Agric. ');
    abbrev = replace($abbrev, 'Arrondissement','Arrond.');
    abbrev = replace($abbrev, 'Aspirant ','Asp. ');
    abbrev = replace($abbrev, 'Colonel ','Col. ');
    abbrev = replace($abbrev, 'Commandant ','Cdt. ');
    abbrev = replace($abbrev, 'Commercial ','Cial. ');
    abbrev = replace($abbrev, 'Coopérative ','Coop. ');
    abbrev = replace($abbrev, 'Division ','Div. ');
    abbrev = replace($abbrev, 'Docteur ','Dr. ');
    abbrev = replace($abbrev, 'Général ','Gén. ');
    abbrev = replace($abbrev, 'Institut ','Inst. ');
    abbrev = replace($abbrev, 'Faculté ','Fac. ');
    abbrev = replace($abbrev, 'Laboratoire ','Labo. ');
    abbrev = replace($abbrev, 'Lieutenant ','Lt. ');
    abbrev = replace($abbrev, 'Maréchal ','Mal. ');
    abbrev = replace($abbrev, 'Ministère ','Min. ');
    abbrev = replace($abbrev, 'Monseigneur ','Mgr. ');
    abbrev = replace($abbrev, 'Médiathèque ','Médiat. ');
    abbrev = replace($abbrev, 'Bibliothèque ','Bibl. ');
    abbrev = replace($abbrev, 'Tribunal ','Trib. ');
    abbrev = replace($abbrev, 'Observatoire ','Obs. ');
    abbrev = replace($abbrev, 'Périphérique ','Périph. ');
    abbrev = replace($abbrev, 'Préfecture ','Préf. ');
    abbrev = replace($abbrev, 'Président ','Pdt. ');
    abbrev = replace($abbrev, 'Régiment ','Rgt. ');
    abbrev = replace($abbrev, 'Saint-','Sᵗ-');
    abbrev = replace($abbrev, 'Sainte-','Sᵗᵉ-');
    abbrev = replace($abbrev, 'Sergent ','Sgt. ');
    abbrev = replace($abbrev, 'Université ','Univ. ');

    abbrev = regexp_replace($abbrev, 'Communauté d.[Aa]gglomération','Comm. d''agglo. ');
    abbrev = regexp_replace($abbrev, 'Communauté [Uu]rbaine ','Comm. urb. ');
    abbrev = regexp_replace($abbrev, 'Communauté de [Cc]ommunes ','Comm. comm. ');
    abbrev = regexp_replace($abbrev, 'Syndicat d.[Aa]gglomération ','Synd. d''agglo. ');
    abbrev = regexp_replace($abbrev, '^Chemin ','Ch. ');
    abbrev = regexp_replace($abbrev, '^Institut ','Inst. ');
    abbrev = regexp_replace($abbrev, 'Zone d.[Aa]ctivité.? [Éeée]conommique.? ','Z.A.E. ');
    abbrev = regexp_replace($abbrev, 'Zone d.[Aa]ctivité.? ','Z.A. ');
    abbrev = regexp_replace($abbrev, 'Zone [Aa]rtisanale ','Zone Art. ');
    abbrev = regexp_replace($abbrev, 'Zone [Ii]ndustrielle ','Z.I. ');
    abbrev = regexp_replace($abbrev, ' [Pp]ubli(c|que) ',' Publ. ');
    abbrev = regexp_replace($abbrev, ' [Pp]rofessionnel(|le) ',' Prof. ');
    abbrev = regexp_replace($abbrev, ' [Tt]echnologique ',' Techno. ');
    abbrev = regexp_replace($abbrev, ' [Pp]olyvalent ',' Polyv. ');
    abbrev = regexp_replace($abbrev, '[EÉeé]tablissement(|s) ','Éts. ');
    abbrev = regexp_replace($abbrev, ' [Mm]unicipal(|e) ',' Munic. ');
    abbrev = regexp_replace($abbrev, ' [Dd]épartemental(|e) ',' Départ. ');
    abbrev = regexp_replace($abbrev, ' [Ii]ntercommunal(|le) ',' Interco. ');
    abbrev = regexp_replace($abbrev, ' [Rr]égional(|e) ',' Région. ');
    abbrev = regexp_replace($abbrev, ' [Ii]nterdépartemental(|e) ',' Interdép. ');
    abbrev = regexp_replace($abbrev, ' [Hh]ospitali(er|ère) ',' Hospit. ');
    abbrev = regexp_replace($abbrev, ' [EÉeé]lectrique ',' Élect. ');
    abbrev = regexp_replace($abbrev, ' [Ss]upérieur(|e) ',' Sup. ');
    abbrev = regexp_replace($abbrev, '^[Bb][aâ]timent ','Bât. ');
    abbrev = regexp_replace($abbrev, '[Aa]éronautique ','Aéron. ');

    return abbrev;
    
$$ LANGUAGE 'plpgsql' IMMUTABLE;

I am trying to change the language of my own OSM tile server from English to my language i.e. Hindi. I have followed the steps as you explained in your repo. I am able to see all the changes in my database. I am not able to see the word "भारत" to the map on browser shown here.

One more doubt I am having is on entering the centroid point of India I am not getting country code"in".

gis=# select osml10n_get_country(ST_GeomFromText('POINT(82 21)', 4326));
 osml10n_get_country 
---------------------
 
(1 row)

Operating System- Ubuntu 14.04 LTS
Thanks in advance for your help

I am building the latest release v2.5.8 using make deb on Ubuntu 16.04.

This fails on the osml10n--$(EXTVERSION_OLD)--$(EXTVERSION).sql: osml10n--$(EXTVERSION).sql target, as the installed tail (GNU coreutils 8.25) doesn't have the +3 option. Did you mean tail -n +3?

Hi, I requested this extension to be added to the Google's Cloud Platform PostgreSQL. Please add a vote (click on the ⭐ left of the title). Thanks for the great extension!

While this project worked reasonably well for producing raster tiles on German Tileserver in recent years and has also been used by OpenMapTiles the current approach showed its limitations recently.

1st Issue

The project is currently using three FOSS transcription libraries. These are:

• ICU for general purpose transcription, http://site.icu-project.org/, written in C++
• Kakasi for Kanji transcription, http://kakasi.namazu.org/, written in C
• tltk for Thai language, written in Python

Back in November Issue #35 was filed and another library pinyin_jyutping_sentence written in python has been found for this purpose.

As we had already noticed with tltka general problem of python shared procedures seemed to be, that imported modules are not persistent between connections in PostgreSQL. Thus imports which take a long time (15 seconds in case of pinyin_jyutping_sentence on my desktop computer and 5 seconds for tltk) will do this not only once but any time a new connection is made to the database.

2nd issue

Also back in November @chatelao added a couple more regular expressions for languages we did not have code for generating street abbreviations yet. Unfortunately this code also slowed down execution time of the functions by an order of magnitude as @otbutz reported in issue #40

Conclusion

Given the fact, that importing OSM data to PostgreSQL is in practise done by osm2pgsql or imposm only, those tools might be a better place to do localization. Currently (AFAIK) just osm2pgsql has the ability to do tag-transformations in import stage, but up till recently had a very static table setup of the target database. Fortunately this just changed with the advent of its new flex backend.

Basically this is why I think we should move the l10n stage to the PostgreSQL import stage instead of keeping it as stored procedures.

Another thing is the actual implementation of Latin transcription. I have a prove of concept implementation which will do this, keeping the approach of the current project for now available at https://github.com/giggls/osml10n.

The idea is to have an external daemon which does the actual transcription while either a script run during import time from osm2pgsql or a replacement for the current osml10n_cc_translit function will connect to this daemon to get a transliterated version of a given string.

This will at least resolve the problem of slow transcription procedures written in python. However, the regular expression problem might only be resolvable by moving this stuff into a (lua-)script running from osm2pgsql.

I am looking forward to your comments.

To fix errors during make dep, I had to to install the following package in addition what is listed in README.md on Ubuntu 16.04:

apt-get install postgresql-server-dev-all

Tested on f557ef1

For newer ICU version the define U_USING_ICU_NAMESPACE must be defined. One possible solution:

`diff -ur osml10n-20180913/icutranslit/Makefile osml10n-20180913_fix/icutranslit/Makefile
--- osml10n-20180913/icutranslit/Makefile 2018-08-19 13:12:56.000000000 +0200
+++ osml10n-20180913_fix/icutranslit/Makefile 2018-09-13 19:15:28.575183123 +0200
@@ -10,7 +10,7 @@
OBJ = osml10n_translit.o

%.o: %.cpp

•   $(CXX) $(CFLAGS) -c $<
  

•   $(CXX) $(CFLAGS) -c $< -DU_USING_ICU_NAMESPACE=1
  

osml10n_translit.so: osml10n_translit.o
$(CXX) -shared -o $@ $< $(LIBS)
`

Guten Tag, es gibt auch im Französischen jede Menge an Abkürzungen für Orte / Strassen Prefixes:

• https://www.canadapost.ca/tools/pg/manual/PGaddress-f.asp#1460716

Häufig gebraucht:

• Chemin: Ch
• Route: Rte

Former german villages in Poland are often tagged with old_name:de=* instead of name:de=*.

Is it possible/useful to add the old_name if there is no name:de-tag?

According to the official city map of Madrid, "Calle" is abbreviated "C."

• https://www.esmadrid.com/sites/default/files/documentos/mapazonasturisticasmadrid.pdf

It seams to be as frequent as "Street" and "Strasse".

I tried mapnik-german-l10n in alpine linux.
I find cat -s in shell script can't run alpine linux(busybox)'s cat command.
I remove it, I can install mapnik-german-l10n.

When multiple postgresql versions are installed, it seems you can only build for the newest version.
Did I overlook something obvious?

I found the following last/newest(?) installed postgresql version dependent settings:

files:
debian/rules:

  PGVERSION=`pg_buildext supported-versions $(CURDIR) | tail -l` || exit $$?;

Makefile:

  EXTDIR=$(shell pg_config --sharedir)

icutranslit/Makefile
pg_config is used twice (always linked to newest or last installed version?)

kanjitranscript/Makefile
pg_config is used twice

I was able to build for other versions as follows:
file debian/pgversions
replace 9.6+ by version number you wish to build for, example: 12

file Makefile:

PGVERSION=12
PG_CONFIG=/usr/lib/postgresql/$(PGVERSION)/bin/pg_config
EXTDIR=$(shell $(PG_CONFIG) --sharedir)

file icutranslit/Makefile

PGVERSION=12
PG_CONFIG=/usr/lib/postgresql/$(PGVERSION)/bin/pg_config
PGPATH=$(shell $(PG_CONFIG) --includedir-server)
...
install -D -m 644 osml10n_translit.so $(DESTDIR)$(shell $(PG_CONFIG) --pkglibdir)/osml10n_translit.so

file kanjitranscript/Makefile

PGVERSION=12
PG_CONFIG=/usr/lib/postgresql/$(PGVERSION)/bin/pg_config
PGPATH=$(shell $(PG_CONFIG) --includedir-server)
..
install -D -m 644 osml10n_kanjitranscript.so $(DESTDIR)$(shell $(PG_CONFIG) --pkglibdir)/osml10n_kanjitranscript.so

now I was able to override the postgres version number as follows:

1. update the version number in debian/pgversions to XX
2. make PGVERSION=XX deb
   where XX is the version number you want to build for.

If you run make deb on a freshly checked out version (f17d7dc) on Ubuntu Linux 18.04, then do git diff, you get:

diff --git debian/control debian/control
index 281c978..ef4103d 100644
--- debian/control
+++ debian/control
@@ -8,13 +8,13 @@ Build-Depends: debhelper (>= 8.0.0), libicu-dev,
  curl, libkakasi2-dev, libutf8proc-dev, pandoc
 Standards-Version: 3.9.2
 
-Package: postgresql-11-osml10n
+Package: postgresql-10-osml10n
 Architecture: any
 # "postgis" is used as some kind of meta package here, because it
 # contains all dependencies for whatever version of PostGIS is available
 # on the Debian or Ubuntu intallation this code is going to get built
-Depends: ${shlibs:Depends}, ${misc:Depends}, postgresql-11, icu-devtools
-Recommends: postgresql-plpython3-11, python3-matplotlib, python3-pip, postgis
+Depends: ${shlibs:Depends}, ${misc:Depends}, postgresql-10, icu-devtools
+Recommends: postgresql-plpython3-10, python3-matplotlib, python3-pip, postgis
 Description: l10n package for generation of OSM based maps from PostGIS
  localisation package  for generation of OSM based maps from PostGIS.
  This is currently used in german mapnik style but can be used in a

i.e. make deb changes files which are checked into git. This doesn't seem right. Same thing happened on an Ubuntu Linux 20.04 server.

get_localized_name_from_tags.sql line 162
"regexp_match(" should be changes to "regexp_matches("
otherwise postgis Extension l10n thrown exceptions on certain queries

Instead of messing up the code, I'll just provide the norwegian street type names and their abbreviations here

vei: v.
veg: v.
gate: gt.
alle: not sure
veite/veita: not sure
smug: not sure

Hope this is of any use, thanks for a great talk in Bonn!

Hi,

the default target variable is DESTDIR not TMPTARGET.

Can you please change this for easier RPM release.

Currently, the transliteration process in this project defaulted to use Mandarin to transliterate all Chinese texts. However, In Hong Kong and Macau, Cantonese is the common language being used by people to read Chinese instead of Mandarin and place name romanization in both places usually use Cantonese to romanize the names instead of using Mandarin, and thus please try to transliterate Chinese name in both places using Cantonese instead of Mandarin Chinese.

I installed the dependencies manually and missed curl:

Therefor the script generated an empty country_osm_grid.sql and i wasn't able to install the extension.

I would suggest to

1. mention curl as a dependency
2. check the return code of the curl download in the script or at least check if gunzip returned with exit code 0

Edit: fixed URL

I have installed the plugin according to instructions. Everything seems to work okay, but from time to time, renderd produces the following error message:

RROR: failed to render TILE default 6 32-39 32-39
Nov 01 18:27:42 mapserverrenderd[59251]: reason: Postgis Plugin: ERROR: column "idxnl" does not exist
LINE 1: SELECT idxnl
^
QUERY: SELECT idxnl
CONTEXT: PL/pgSQL function osml10n_gen_combined_names(text,hstore,boolean,boolean,boolean,boolean) line 144 at assignment
PL/pgSQL function osml10n_get_names_from_tags(hstore,boolean,boolean,text,geometry) line 12 at RETURN
PL/pgSQL function osml10n_get_placename_from_tags(hstore,boolean,boolean,text,text,geometry,text) line 9 at assignment
in executeQuery Full sql was: 'SELECT ST_AsBinary("way") AS geom,"name","way_pixels" FROM (SELECT
ST_PointOnSurface(way) AS way,
way_area/NULLIF(POW(8.73566e+060.0010.28,2),0) AS way_pixels,
localized_name_first as name,
ref
FROM planet_osm_polygon
WHERE way && ST_SetSRID('BOX3D(-313086.0678562499 -5322463.153556248,5322463.153556248 313086.0678562499)'::box3d, 3857)
AND boundary = 'administrative'
AND admin_level = '4'
AND name IS NOT NULL
AND way_area > 1002445.98::real2445.98::real
AND osm_id < 0
ORDER BY way_area DESC
) AS state_names'

Some background info: I'm trying to use mapnik-german-I10n together with openstreetmap-carto-de. I have created the necessary views. I'm not exactly sure what's wrong - maybe the error is with my OSM import?
I could not find any reference to a column called idxnl save for in mapnik-german-I10n.

Best Regards

The following query takes about 3.3 seconds when executed with version v.2.5.7 or v2.5.8 in PostgreSQL 12.1 / Postigs 3.0:

SELECT localized_streetname
FROM planet_osm_line
WHERE "way" && ST_SetSRID('BOX3D(1222380.956336539 6339381.37785938,1233387.888409604 6350388.309932444)'::box3d, 3857)

If i drop the extension and reinstall v2.5.6 instead, the same query finishes within 400ms.

Edit: Discussion on the psql-bugs mailinglist: https://www.postgresql.org/message-id/20200204162901.s5hbfrl2ylb3jjsq%40alap3.anarazel.de (BUG #16241)