As I noted a couple weeks ago, I was unable to render the image for the Cleveland neighborhood map. After a couple weeks of troubleshooting [all noted , I finally fixed the problem. Hoping to have the version2.0 release in a couple days !
Below is a log of the troubleshooting that I’ve done over the past couple weeks.
A couple notes [also see the diagram in my previous blog post for reference
.osm file – contains geographic data, like the location of streets, cities, trees, and other features, within a specific space (noted by longitude and latitude).
The rules file (.XML) (known as osm-map-features .xml in the diagram) – the rules file defines properties of the map: colors, size of objects [like streets, railroads] for the entire area that is in the data in the .OSM
Then you run a program that takes the .osm file and the specified rules file into an SVG [this process is called rendering].
The problem in detail:
I downloaded another .osm file of the city of Cleveland that included the collinwood area (I named this data file version 2.0).
I also modified the rules file because I wanted to increase the size of the Cleveland’s administrative borders. I dubbed this modified rules file as ‘rules2.0’
I went through the same rendering workflow as I previously did, using xsltproc to create the SVG. I rendered twice to create 2 SVG
files, version2-draft1 and version2-draft2.svg [draft 2, because I edited the rules map to also include a scale]
Eye of gnome [the default image viewer for ubuntu] and the gimp didn’t show the administrative borders for these SVGs.
At first, I thought maybe I damaged something in the 2.0 rules file. Nope. I decided to try render a small part of Collinwood.
That SVG displayed fine, with the larger administrative borders in the gimp and eye of gnome….
At this point, it was round Nov. 18th, I was still unsure why the borders weren’t showing.
Meanwhile, xsltproc was taking 6 hours each time to render the version2.0 data. I talked to the friendly people in OSM [OpenStreetmap]’s IRC channel and after troubleshooting with a couple members, mostly with petschnge, I decided to comment nearly everything out of the rules, so that the borders and little else would be rendered in the SVG (I named this rules file, 3.0). I had hoped by commenting most things out of the rules file, except for the borders, the rendering would go much faster and then go from there.
Unfortunately, the rendering was not any faster – still 6 hours, and the borders still had not shown in the gimp or eog.
I mentioned this to petschnge, and I sent him/her my rules and data files. petschnge had rendered version 1.x data and the version 2.0 data using the 3.0 rules file.
He noted that borders did appear in his rendered SVGs ! I was excited, then I found out the borders for both SVGs were appearing – in inkscape.
Additionally, he had rendered them through a perl script, known as Osmarender/perl or or/p which produced SVGs much smaller in disk size, only 4 or 5mb each, compared to 10+mb ones that were created through xsltproc
As I downloaded them from him and opened the SVG made according to the 1.x data [with the 3.0rules], the borders appeared in the eye of gnome and the gimp. As I opened the ones made with the 2.0 data, no borders appeared in the gimp or eye of gnome.
The problem all along had been the gimp and the eye of gnome [both programs are probably using the same library to display the SVG, I imagine] being unable to display the borders in very large SVGs, [in terms of the image’s width]. I’ll file a bug about this in gnome’s bugzilla soon.
Yet, the story is not over yet. Will post part 2 of it very soon.