Hi Keng,
i know this is unsatisfactory. But unfortunately this is a known problem with mapnik, the software usually used to render maps with OSM data. Besides the osmarender maps (TAH) all OSM maps I am aware of suffer from this problem.
so on my map there is nothing I can do to fix it.
If you know someone who is familiar with C++ programming and could work on this topic it could speed up a bugfix.
https://github.com/mapnik/mapnik/issues/112
Stephan
Hello keng,
welcome to the OSM community and the forum. Glad to see one mapper more mapping names in Thai.
The “_ี” below the consonant instead above is quite strange. I mapped already quite a lot and never saw this. Hopefully not to tough for Stephan to fix.
I see you prefer another method of romanization: e.g. “_ี” becomes “ee”. As described on the page WikiProject Thailand I’m using RTGS and “_ี” becomes “i”. This comes closer to my mother language German and to IPA (International Phonetic Alphabet). On signs I saw both versions even on different signs of the same village or street.
In addition I noticed the tagging of name:th and int_name. I stopped using name:th where it’s just a duplication of name. It adds to the database size. I learned that it’s quite easy for programs to recognize Thai due to the different charcter set. See e.g. mkgmap. For Thailand there’s an OSM map available with weekly updates on Free routable maps for Garmin brand GPS devices which I use on a Garmin phone and with the Windows program MapSource.
“int_name” I’m tagging only if it’s different from “name:en”, e.g. “int_name=Bangkok” for “name=กรุงเทพ”.
Happy mapping
Willi
Hi Willi,
Database size is nothing to really worry about. We just have a few thousand names. That impact is neglectable.
I still use name:th as from time to time some “clever” people optimize the map on osm.org by replacing Thai script with English names.
with name:th i still have an easy way to automatically detect these cases.
If we agree someday in the future we no longer need it it just takes me 5 minutes to get rid of them by using an automated edit.
Currently it does not harm.
int_name is deprecated. Better use name:en. Only for special cases it might make sense as Willi already explained.
Some people are discussing to distinguish English names and transliterations. Maybe this is too much for now.
I hope my Thai will be better some day so I can read Thai names without problems. Until then the current name:en is helping a lot already.
For a map of Thailand having a Thai script name should be the primary goal.
If a tourist map is showing “Sukhumvit Road” or “Thanon Sukhumvit” is just a small issue without any practical impact on a tourist. They could use both to find their way.
Stephan
The map on openstreetmap.org shows the actual section of the border between the provinces Khon Kaen and Chaiyaphum which is the Choen River, changed on September 15th. I recognised today that the Thaimap still shows the old version. But the render status is of today.
As noted on the main page I’m in the process of updating all software involved to current versions as well as reimport ODbL to meet legal requirements. There had been software crashes of the upgrade path due to mismatches of the involved tools. I thought I had fixed it, but obviously something stayed broken. I now re-imported all changesets from 14th onwards.
That should have repaired most.
In the near future I hope to be able to upgrade the database as well. It’s also needed because we will run out of node ids that fit in 32bit in the next months. After this upgrade all tiles will be re-rendered to comply with legal requirements.
Sorry for inconvenience. Please report any further inconsistencies after the completion of the upgrade.
Stephan
Update of the server should be done. I upgraded the complete rendering stack, now using up to date versions of mod_tile, tirex, postgresql, postgis and mapnik. Data is fresh imported to comply with ODbL and be ready for 64bit IDs.
Functionality looks ok, please have an open eye and let me know if something is not working as expected. All tiles are marked as dirty and will be rerendered upon first request.
Line spacing in the Bilingual labels is bigger than before, this is default current style of OSM and mapnik. I’ll have a look at this later and try to make it a bit smaller.
http://thaimap.osm-tools.org/
Stephan
That’s quite strange. That way was created 25 Aug 2012, the data I used for the import was much newer. I see no reason why it should be missing.
Also this morning my hosting provider did a hard shutdown of the server some tables in the DB could not be recovered. So from this morning 9UTC onwards some updates might be missing. Also name hinting on nametool.osm-tools.org is no longer working.
I try to figure out what’s the problems with the updates before triggering a complete reload of the data. It’s a bit annoying if parts of the data are missing. And especially if there is no clear reason for it.
Sorry for inconvenience and a big thank you to Willi for keeping an eye on the synchronization problems.
Stephan
Also road #44 happens to partially disappear: only the North bound carriageway is rendered. But #44 is complete South of the intersection with #41…
Hm, the East bound carriageway of #401 has a surface tag, the West bound one hasn’t. The North bound carriageway of #44 has a source tag, the South bound one hasn’t…
Currently I have no idea what is going wrong. Data seems to be in the database, should render.
I asked on IRC and on the mailing list for help, but no one came up yet with an idea of what could be wrong.
Not sure if it is tirex, mapnik, the style or some unlucky combination of these…
http://lists.openstreetmap.org/pipermail/dev/2012-October/025727.html
Any hints appreciated
Stephan
Seems to be a tricky and big problem. Discovered an unconnected junction, last changed yesterday: osm.org
Hi,
want to give a status update:
It looks like all was caused by the unclean shutdown of my server by netcup (my hosting provider). They had to do maintenance because the server did show frequent thermal throttle events. This is caused by the CPU overheating, usually an indication of a cooling problem.
I had expected they send a shutdown command before shutting down the vserver. Unfortunately this did not happen and the database came up unclean and reverted the unlogged tables to a blank state.
Unlogged tables are a new feature of postgresql. They should speed up imports into the database as no logfile is written for rollback. I thought it’s safe to skip as I imagined worst case to roll back the replication state file.
All missing ways seem to be changed after the crash of the DB Tuesday morning which killed the node lookup table used by the update process. I suppose they get lost after the lookup does not return valid nodes.
My analysis was delayed due to the fact that I looked up the wrong way in the db (the still existing one) and wondered what broke the rendering. In fact it was the replication of the database which was broken.
Yesterday I started another import of the data, using the bounding box including Thailand, Laos, Vietnam, Cambodia (97.3,5.6,109.6,23.4) as I discovered the severity of the broken DB.
I experience a much slower update speed as I knew from the past. Last year a full reload of that bounding box completed within three hours.
It could have happened that the amount of data increased a lot, that osm 64bit IDs slows down the process or that postgresql 9.2 is slower in the configuration used. Or the server has a different scheme to allocate the resources or the general load on the server increased (it’s a shared vserver).
Currently the import is running since 24h, largely IO bound as can be seen on the iowait times in the graph.
Updates are disabled until the import is completed, the currently served map tiles are the cached ones. There are already 60.000, so most parts of Thailand should display fine on the map.
I expect the import to be completed in a few hours, after that I will restart the replication which will also need a few hours to catch up. The current age of the data is available on the about page of the nametool, in case someone is interested.
A dedicated server would perform much better but I’m currently not willing to pay 600 EUR a year for OSM server hardware.
This is a typical hardware needed: http://www.hetzner.de/en/hosting/produkte_rootserver/ex4
Increased performance options would be +10EUR for additional 16GB RAM, +19EUR for 240GB SSD monthly.
Renting a server in Thailand is a lot more expensive, I have not yet seen anything comparable. So if we could come up with a solution to finance a dedicated server I’m willing to manage it.
For your infomation, this is the setup I’m currently using: http://www.netcup.de/bestellen/produkt.php?produkt=87
Stephan
Removed
This is done when OpenLayers can’t load a matching map tile. Currently there is a severe server problem which occurred after the migration to up to date software and data.
As of now the import is completed. For unknown reasons the database increased to 41GB. This is over 40 times the average size of last year. This is literally killing the server.
My current hypothesis is that the bounding box filtering of osm2pgsql is not working in combination with pbf format imports. I’m running handcrafted queries to remove data from the database which does not belong to the bounding box usually shown on the map. Due to the huge amount of data which needs to be processed this is taking a while. I hope that later this night the load is back at a normal level.
Then I’ll restart replication to have the data back at a current state. Map updates should be working already but will be very slow until the server load is back at a normal level.
I’m sorry that I currently can’t provide the bilingual map and other assist services like nametool or the naming reports in the quality OSM Thailand deserves. I’m working hard on a solution and will keep you updated. Thanks in advance for your kind understanding.
Stephan
Good news. Since about 30 minutes the bilingual rendering is up and running again.
I changed the import process as osm2pgsql is broken. Now the data is preprocessed with osmconvert.
I checked some areas I know and the rendering looks fine.
I did reset all tiles so in case you visit an area the first time the tiles will be freshly rendered which can take a few seconds (most 8x8 metatiles are rendered faster than 1s).
Please have a look if your edits appear on the map as expected. As I did use new tooling for the import there is a small chance that something else is broken.
Thank you for your patience.
Stephan
Great, thanks! #44 and #401 look good now.
Thanks. As far as I checked back to normal operation. Unfortunately major and sometimes also minor changes have their pitfalls.
Unfortunately there are still problems.
By doing a thorough examination of the database I discovered duplicate entries.
For example the AH2 relation (229600) is 237 times in the database.
Very likely this is also related to only serving a small extract of the world.
I’m trying to reproduce the problem with a test database, probably another problem with osm2pgsql.
The last one is in trac, but still without solution:
https://trac.openstreetmap.org/ticket/4625
Only ways and relations are affected. If you encounter strange renderings of ways or relations, please also report the OSM ID so I can check the database.
I guess this problem existed for a longer time as there had been strange effects before.
Good news: the duplicate entries is normal behavior. So I expect the database working fine now.
Stephan
edit: updated post regarding duplicates
