Hi,
The nicest way I know is using some xslt from here:
https://lists.berlios.de/pipermail/mapnik-users/2008-June/000986.html
This produces a neatly formatted page listing all the layers, styles
and
rules with min/max zooms and mouse-overs with details of css
parameters
etc.
I took a
On Tue, Jan 27, 2009 at 11:43:29AM +0100, Dirk Stöcker wrote:
On Tue, 27 Jan 2009, Marko Mäkelä wrote:
Recently, I started contributing to OpenStreetMap. I would like to
contribute to JOSM as well. To start, I wanted to improve some Finnish
translations. However, I noticed a few problems
Ivo,
Casing is the border of the road, whereas the fill is the colour in the centre.
You’ll see that these are two overlapping lines, with the casing slightly wider
than the fill, such that just either edge shows through once the fill is drawn
on top.
Cheers,
Gregory
From:
Ivo wrote:
minor-roads
minor-roads-casing
5 000
1 000
☡
([highway] = 'secondary' or [highway] =
'secondary_link') and not ([tunnel]='yes' or [tunnel]='true')
CSS:
stroke: #a37b48
[Moved to dev; followups to dev]
On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason wrote:
I think multiple keys with the same name should be allowed for a
node/way/relation. AFAIK it's only the editors that don't currently let
you do this.
Yes, the API and data format
On Wed, Jan 28, 2009 at 01:18:53AM +0100, Stefan de Konink wrote:
Is using different keys (when they’re likely to be unknown to the
renderers) or multiple tags with the same key name any better supported
in the renderers?
The most logical way of tagging is still using the xml namespace
Simon Ward wrote:
Ok, pulling up the wiki page on API 0.6[1] I see that the plan is “to
create an unique index on the combination of object id and tag key”.
Presumably this is mainly for performance. An index doesn’t have to be
unique though—is this a limitation of MySQL or is there some
On Wed, Jan 28, 2009 at 12:18 AM, Stefan de Konink ste...@konink.de wrote:
Simon Ward wrote:
I think that leaves us with an unoptimal situation where editors
either have to shove things into the same key delimited by some token
like ; as is currently recommended but AFAIK not supported by any
On Wed, Jan 28, 2009 at 12:30:01AM +, Tom Hughes wrote:
In practice keys are unique because although the API has never enforced
uniqueness pretty much every client does because all the clients use a
hash table of some sort to store tags.
Hash table, or associative array/hash/dictionary?
Tom Hughes wrote:
In practice keys are unique because although the API has never enforced
uniqueness pretty much every client does because all the clients use a
hash table of some sort to store tags.
Except for editors like Potlatch that use intermediate layers to access
the API and screw
Hi,
Simon Ward wrote:
Hash table, or associative array/hash/dictionary? Hash tables have
mechanisms to deal with collisions.
A collision in a hash table is two keys sharing the same hash value, not
two keys being identical.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org
Stefan de Konink wrote:
Except for editors like Potlatch that use intermediate layers to
access the API and screw up the uniqueness.
In what way does Potlatch screw up the uniqueness, please?
Richard
--
View this message in context:
Richard Fairhurst wrote:
Stefan de Konink wrote:
Except for editors like Potlatch that use intermediate layers to
access the API and screw up the uniqueness.
In what way does Potlatch screw up the uniqueness, please?
http://api.openstreetmap.org/api/0.5/way/24644162/history
Stefan
Stefan de Konink wrote:
Richard Fairhurst wrote:
In what way does Potlatch screw up the uniqueness, please?
http://api.openstreetmap.org/api/0.5/way/24644162/history
does not even begin to be an answer. It could be caused by the bleeding
phase of the moon for all that tells me. I was hoping,
Stefan de Konink wrote:
Richard Fairhurst wrote:
In what way does Potlatch screw up the uniqueness, please?
http://api.openstreetmap.org/api/0.5/way/24644162/history
does not even begin to be an answer. It could be caused by the bleeding
phase of the moon for all that tells me. I was hoping,
Richard Fairhurst wrote:
Stefan de Konink wrote:
Richard Fairhurst wrote:
In what way does Potlatch screw up the uniqueness, please?
http://api.openstreetmap.org/api/0.5/way/24644162/history
does not even begin to be an answer. It could be caused by the bleeding
phase of the moon for all
2009/1/28 marcus.wolsc...@googlemail.com
On Wed, 28 Jan 2009 00:07:20 +, Simon Ward si...@bleah.co.uk wrote:
[Moved to dev; followups to dev]
On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
wrote:
I think multiple keys with the same name should be allowed for a
2009/1/28 D Tucny d...@tucny.com
2009/1/28 marcus.wolsc...@googlemail.com
On Wed, 28 Jan 2009 00:07:20 +, Simon Ward si...@bleah.co.uk wrote:
[Moved to dev; followups to dev]
On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
wrote:
I think multiple keys with the
Hi all,
Recently, I started contributing to OpenStreetMap. I would like to
contribute to JOSM as well. To start, I wanted to improve some Finnish
translations. However, I noticed a few problems with
http://svn.openstreetmap.org/applications/editors/josm/i18n/build.xml
that I would like to fix
On Tue, 27 Jan 2009, Marko Mäkelä wrote:
Recently, I started contributing to OpenStreetMap. I would like to
contribute to JOSM as well. To start, I wanted to improve some Finnish
translations. However, I noticed a few problems with
If you do, please do on Launchpad and not directly in SVN.
On Tue, 27 Jan 2009, Marko Mäkelä wrote:
On Tue, Jan 27, 2009 at 11:43:29AM +0100, Dirk Stöcker wrote:
On Tue, 27 Jan 2009, Marko Mäkelä wrote:
Recently, I started contributing to OpenStreetMap. I would like to
contribute to JOSM as well. To start, I wanted to improve some Finnish
Am 23.01.2009 08:47, Dirk Stöcker:
On Thu, 22 Jan 2009, Claudius Henrichs wrote:
please replace the OpenBrowser with a nice In-Java
display like for the help pages. This OpenBrowser call is a crude
workaround.
I prefer opening the system browser because the user has the possibility
to
22 matches
Mail list logo
