Hi,
marcus.wolsc...@googlemail.com wrote:
I remember someone saying that we had them once and abadoned the idea.
This is true. On the other hand, I heard someone say that intelligent
people may change their minds ;-)
Also it is way too late to add new primites to API 0.6 already.
Most
Hi,
i've searched the archive of this mailinglist and the wiki about the
magical y-boundary set to 85.05113° (respective 180° projected) in the
Mercator Projection.
The Wiki says [1]:
By using this bound, the entire map becomes a (very large) square.
Is this the only reason for this
Tom Hughes wrote:
Matthias Brandt wrote:
i've searched the archive of this mailinglist and the wiki about the
magical y-boundary set to 85.05113° (respective 180° projected) in
the Mercator Projection.
Did you have an alternative value in mind?
Not really. But I would like to know, if
Matthias Brandt wrote:
Tom Hughes wrote:
Matthias Brandt wrote:
i've searched the archive of this mailinglist and the wiki about the
magical y-boundary set to 85.05113° (respective 180° projected) in
the Mercator Projection.
Did you have an alternative value in mind?
Not really. But I
Tom Hughes wrote:
Matthias Brandt wrote:
Tom Hughes wrote:
Matthias Brandt wrote:
i've searched the archive of this mailinglist and the wiki about
the magical y-boundary set to 85.05113° (respective 180° projected)
in the Mercator Projection.
Did you have an alternative value in mind?
Ticket #2134 ( http://josm.openstreetmap.de/ticket/2134 ) brought it
to my attention that it may be a good idea to warn users if the JVM
doesn't allow a reasonable amount of memory to be allocated. The
implementation won't be so hard, just present a dialog with the
appropriate command line args
It should be noted that the user can pass arguments to the java
command to tell the JVM to use more memory. I do this all the time,
quite often setting it to 2 or 3GB.
Shaun
On 4 Feb 2009, at 13:42, Stefan Breunig wrote:
Ticket #2134 ( http://josm.openstreetmap.de/ticket/2134 ) brought it
Matthias Brandt wrote:
i've searched the archive of this mailinglist and the wiki about the
magical y-boundary set to 85.05113° (respective 180° projected) in the
Mercator Projection.
The Wiki says [1]:
By using this bound, the entire map becomes a (very large) square.
Is this the
Hi,
Matthias Brandt wrote:
Not really. But I would like to know, if there is any reason for this.
I'm writing my Bachelorthesis about OpenStreetMaps and I would like to
explain this bound.
Simly omit any explanation and if asked by your professor say: Did you
have an alternative value in
punting to dev@
Begin forwarded message:
From: RICHARDS T.W. t.w.richa...@durham.ac.uk
Date: 3 February 2009 09:54:03 PST
To: st...@asklater.com
Subject: Static Maps URL
Hi,
I am a student at Durham University, working on a software
development project to create a geocaching game.
I have
El Miércoles, 4 de Febrero de 2009, SteveC escribió:
I have been using Google Static Maps API, to download tiles, for my
PDA application, however it isn't quite flexible/accurate enough for
me to stitch together the tiles, so I have been looking into
OpenStreetMap, which looks ideal.
Hi,
If I recall correctly, we had more or less decided to have a limit
of n members to a relation and m nodes to a way in API 0.6.
I can see that the way limit has been implemented and configured to be
2000 nodes per way. Will it remain at 2000 or is there still discussion?
If the number
On Thu, 05 Feb 2009 01:54:14 +0100, Frederik Ramm frede...@remote.org
wrote:
Hi,
If I recall correctly, we had more or less decided to have a limit
of n members to a relation and m nodes to a way in API 0.6.
I can see that the way limit has been implemented and configured to be
2000
Ladies and gentlemen,
I really do not want to abuse anybody, but ... this is spaghetti code.
...Almost everywhere in JOSM.
Most fields which represents GUI components (labels, text fields buttons) in
panels and dialogs are public or have package visibility level.
E.g.
public class
Ladies and gentlemen,
I really do not want to abuse anybody, but ... this is spaghetti code.
...Almost everywhere in JOSM.
Most fields which represents GUI components (labels, text fields buttons) in
panels and dialogs are public or have package visibility level.
E.g.
public class
Igor Shubovych wrote:
I really do not want to abuse anybody, but ... this is spaghetti code.
...Almost everywhere in JOSM.
Quote from wiki (imi):
http://josm.openstreetmap.de/wiki/DevelopingPlugins
First some words about my style of accessing public variables. Most
people find this annoying
Igor,
Igor Shubovych wrote:
I really do not want to abuse anybody, but ... this is spaghetti code.
We don't have GOTOs though.
I suggest you read, and try to understand, the discussion that begins
with this message:
http://lists.openstreetmap.org/pipermail/josm-dev/2008-August/001433.html
2009/2/5 Stephan o...@stephans-server.de
Igor Shubovych wrote:
I really do not want to abuse anybody, but ... this is spaghetti code.
...Almost everywhere in JOSM.
Quote from wiki (imi):
http://josm.openstreetmap.de/wiki/DevelopingPlugins
First some words about my style of accessing
2009/2/5 Frederik Ramm frede...@remote.org
Igor,
Igor Shubovych wrote:
I really do not want to abuse anybody, but ... this is spaghetti code.
We don't have GOTOs though.
I suggest you read, and try to understand, the discussion that begins with
this message:
Hi,
Igor Shubovych wrote:
But what about small refactoring steps. Step by step the code better.
As I see it is histrorical problem, you didn't want to broke the plugins.
There is absolutely nothing to say against stepwise improvement! If
someone says I need to change this because otherwise I
Ok. Sorry for that flame.
Regards,
Igor Shubovych
2009/2/5 Frederik Ramm frede...@remote.org
Hi,
Igor Shubovych wrote:
But what about small refactoring steps. Step by step the code better.
As I see it is histrorical problem, you didn't want to broke the plugins.
There is absolutely
21 matches
Mail list logo
