mapquest / mapquest-mapnik-style Goto Github PK

Some rules have repeated maxscaledenominators when I imagine they are intended to have one minscale- and one maxscale-denominator. There are also some places where the subquery in a "table" parameter defines the same field twice.

I've published corrections for both of these in dwins/MapQuest-Mapnik-Style@24e7f3c and dwins/MapQuest-Mapnik-Style@5306310 respectively.

ref=CR 73/12: http://otile1.mqcdn.com/tiles/1.0.0/osm/18/72976/99568.png
example sign: http://www.flickr.com/photos/andrew-turnbull/5904974507/ (yes, WV uses circles for county routes (actually maintained by the state, but called county routes), and squares for (primary) state routes)

I get the following error by renderd. I have found this in mapquest_inc/layer-text.xml.inc but don't know how to fix it.

Anyone know how to fix the issue?

Postgis Plugin: ERROR: invalid input syntax for integer: "A1"#12#012in executeQuery Full sql was: 'SELECT ST_AsBinary("way") AS geom,"name","place" FROM (select way,place,replace(replace(name,'(',''),')','') as name,ref#012 from planet_osm_point#012 where place in ('continent','country','county','state')#12 or (place in ('city','metropolis') and capital='yes' #12 and (admin_level is null or admin_level::integer < 4))#12 ) as placenames WHERE "way" && ST_SetSRID('BOX3D(-1252344.271424999 -1252344.271424999,11271098.442825 11271098.442825)'::box3d, 900913)'

Offhand I can't find any examples, but I've seen some recently. "US 1;US 9" appears correctly as two U.S. Route shields, but "US 1; US 9" (note the space) puts the 9 in an oval.

When rendering I get the error

RuntimeError: :
ERROR:  operator does not exist: text > integer
LINE 8:         case when population > 0 then population else -1 end...
                                     ^
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.
Full sql was: 'SELECT * FROM
            (select way,
      case when "name:en" is null then name
           when name is null then "name:en"
           when length(btrim(replace(name, "name:en", ''), '()- ')) = 0 then "name:en"
           else "name:en" || E'\n(' || btrim(replace(name, "name:en", ''), '()- ') || ')'
      end as name,
        case when population > 0 then population else -1 end as population
       from planet_osm_point
       where place in ('country')
order by population desc) as countries
           LIMIT 0'
 (encountered during parsing of layer 'placenames-country' in map '/home/pnorman/osm/mapnik/MapQuest-Mapnik-Style/mapquest-us.xml')

This is with postgresql 9.1.3

Changing the SQL to

case when CAST(population as integer) > 0 then CAST(population as integer) else -1 end as population

fixed this, but I am not sure if this is reliable in the case of malformed data (e.g. someone puts free-form text in the population field)

Similar issues may be present elsewhere. If the above changes don't cause errors with invalid data I can submit a patch if desirable.

Hello. Can someone be so kind and explain to me how do these styles work and how can I apply them to my python file for mapnik? Thank you

Hi there,
Could you have a look at this commit: stellaraccident@1eefe59

There are three things going on here. The first one, I think should definitely be finished and make it into your repo. The other two have helped me out but you may or may not want them. Sorry to have committed them in one go:

1. Start externalizing sql. I created a sql entity referencing individual sql files and then include the sql by name in the layers. I have done this (mostly) to the transportation and streetnames layers in the us. Having the SQL broken out helped me understand what was going on and made sure that it was consistent between layers
2. Increased road labeling. In the 'street text' style, I added a rule to render tertiary street names at zoom level 15. Level 15 is a pretty useful scale and needed more labels in my opinion. I have it as a separate rule because I am still playing with options to get the density I'm after. I used a hack that adds spaces as prefix and suffix to the name via an expression to simulate padding and keep things from scrunching up to closely.
3. Reorganize street text layers. I added the columns required for the street name styles to each of the SQL queries for street1,2,3, etc. This will create no overhead on layers that do not have styles that reference these columns and allows us to have that many fewer sql statements. I also expanded the labeling layers so that instead of just doing one "big dip" into the database to get everything that is "road-ish", it discretely renders the text for each road classification separately.

Several of these changes were motivated by a tool I am using that discovers commonalities in the map data and coalesces it on disk. It works better if you have less arbitrary sql running around since it can clearly determine that different layers are referencing the same data. The tool also can be used to generate different detail level batches by simplifying all of the data in one go for higher scale rendering. With that said, even if you are not using this optimization tool, I think these changes are in line with good map file design and should be taken.

Looking at open.mapquest.com I see the TIFF overlays at all zoom levels but after implementing mapquest-us.xml they are not used above zoom 2 and all land is yellow, without any relief (green shaded). Here is a screen shot showing the page with some zoom level 2 and some zoom level 3 tiles - you can easily spot the difference.

Any ideas as to what I could have done wrong here? Thanks!

Railway stations with tag disused=yes should (probably) not be shown in a standard rendering, at least not in the same style as normal ones. Example is this London MailRail station: http://mapq.st/R81feK

In cases where (say) both "name" and "name:en" tags are used, both are included on the map with the non-en name in parentheses. This is clearly intended behaviour for cases where these names differ. However, when they are the same the effect is comical, wasteful and undesired. Suggest that the secondary name only be included where different.

Example: http://open.mapquest.com/?version=1.0&hk=10-eMobsWKE

(Check out the names of rivers Liffey and Dodder and of Grand Canal)

Louisiana has parishes rather than counties. So PR * should be treated like CR *. (But Puerto Rico should be cut out of this rule, I suppose.)

"Historic" is not being recognized as a banner: http://www.openstreetmap.org/?lat=33.41594&lon=-117.14475&zoom=16&layers=Q The US 395 shields are on what is tagged ref=US 395 HISTORIC.

And, most problematically, SR * (State Route/Road?) is now being rendered with a county rectangle rather than the correct state circle. While the overlaps are certainly nice, the wrong shield shape is bad. http://www.openstreetmap.org/?lat=41.4764&lon=-81.6651&zoom=14&layers=Q http://www.openstreetmap.org/?lat=42.2603&lon=-71.8064&zoom=14&layers=Q All the rectangles are tagged SR (state route) and should use the rounded rectangle.

On the plus side, I don't see any more error rounded rectangles for Interstates or U.S. Routes, but this may be a consequence of my recent post-"redaction" once-over that removed most spaces after semicolons. Keep up the good work; showing overlaps is important. And four-character routes are now displayed (not for county roads though?).

This is a great resource to get nice looking maps with OSM data quickly. Thanks.

Since TileMill, etc. seem to be moving in the direction of CartoCSS, what would it take to move these XML files to CartoCSS?

We'd be willing to chip in as needed.

Thanks.

Pankaj (Zee Source)

Hey,
I'm using the mapquest (non-hybrid) eu style to render maps of Germany with mapnik2. I did not modify the styles (except for the templates to match my render setup). But for me the street names for larger roads which should fit into the square road symbols are positioned incorrectly and rotated to match the direction of the road (which they shouldn't be) as you can see here:

http://imageshack.us/photo/my-images/687/mapqueststyle.png/

I don't know whats wrong there, can you help me out a bit?

While this style shows house numbers for any building tagged as building=yes but not for building=house.

This can be seen here:

http://open.mapquest.co.uk/link/9-9tsphqP6

The first few houses in Guildford Park Avenue are building=yes, while all the houses in Lynwood are building=house.

There are three entries which have &maxzoom specified twice instead of &maxzoom &minzoom

All three-digit ref=AR xxx ways appear as Highway 682: http://www.openstreetmap.org/?lat=35.1554&lon=-90.4072&zoom=12&layers=Q

Hi there,

((Sorry if this isn't the correct venue -- I couldn't find a mailing list or the like))

Hi there,

I'm new to mapnik though I've been using GeoServer, GeoTools, etc. for a long time. I'm currently trying to generate Mapquest Open-style maps using OSM data and have gotten pretty far with success, but I'm seeing results I don't understand and could use some advice.

Configuration:

• Windows 7/64
• PostGIS 2.1.3/PostgreSQL 9.3
• Osm2pgsql, current version
• Python 2.7.8
• Mapnik v2.2.0
• Mapquest Open Mapnik config, via github

What's up:

• Installed everything
• Imported OSM data for Colorado
• Ran Mapnik w/Mapquest Open config
• Got an image (attached)

Here's the script I'm using to execute Mapnik, currently:

import mapnik
stylesheet = 'mapquest-us.xml'
image = 'mapquest_test_1.png'
m = mapnik.Map(1000, 500)
mapnik.load_map(m, stylesheet)
m.zoom_to_box(mapnik.Box2d(-109.0603,36.9924,-102.0416,41.0024))
mapnik.render_to_file(m, image)
print "rendered image to '%s'" % image

The results are definitely the state of Colorado, but there are clear level of detail differences with respect to what I see on openstreetmap.org. I suspect I'm invoking Mapnik incorrectly, so I thought it worthwhile to ask if anyone here has tried this with these versions of Mapnik, etc. and/or could point out what I'd missed.

Thank you for your time and please let me know if I may provide any additional information.

There seems to be some missing files:

$ nik2img.py mapquest-us.xml > mapquest.png

I/O warning : failed to load external entity "mapquest_inc/fontset-settings.xml.inc"

Using the stylesheet with the updates2 branch resulted in the error

column "name:en" does not exist

Adding a name:en column to the .style used by osm2pgsql fixed this. This should be documented.

When rendering a map with the style it has the error

### WARNING Marker does not exist: /home/pnorman/osm/mapnik/MapQuest-Mapnik-Style/symbols/shield_sr_us2.svg

Either it should be changed to look in mapquest_symbols or mapquest_symbols should be renamed

Good afternoon, dear experts!

I am performing a project with application of Mapnik to OSM data and on further steps I need to apply MapQuest styles to my map. I am a pure Cartographer and do not have tremendous IT background.

Could you be so kind and explain to me on which stage do I need to embed MapQuest styles, and when should I combine my Python code and XML script with MapQuest styles? I could not find any documents about such procedure.

I will really appreciate if anyone could write me an answer and will be very glad to see someone's respond. Many thank to you and have a nice day!

Additional questions:

1. What is the difference between xml files 'mapquest-eu.xml' and 'mapquest-hybrideu.xml' ?

Any idea where I could find the mercator_tiffs.tar in order for this style to work ? http://developer.mapquest.com/content/static/geotiffs/mercator_tiffs.tar is dead.

ref=LA 611-1: http://otile4.mqcdn.com/tiles/1.0.0/osm/15/8179/13524.png
example sign: https://picasaweb.google.com/lh/photo/eqCwxYgqwttsNXA-tix1gtMTjNZETYmyPJy0liipFm0

ref=CR 1: http://otile4.mqcdn.com/tiles/1.0.0/osm/14/4429/6850.png
ref=CR 44: http://otile1.mqcdn.com/tiles/1.0.0/osm/14/4474/6818.png