Richard Fairhurst wrote:
>
> This is getting crazy.
>
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
>
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
> introduced hundreds of errors. #osm #openstreetmap #whybother"
>
I wonder how many c
Dear Richard and everyone else,
We have a totally different experience here. We have done some import
processes here in Chile, probably not more than four or five till now, I
talked about the suburban highways import process in my "State of Chile"
presentation in Amsterdam, and after that we added
Daniel Sabo wrote:
>
> I would think (or at least hope) that this kind of bad import would be
> less of an issue if the revert tools were not so arcane. My previous
> attempts are reverting stuff have always ended up with manual XML fiddling
> to get the desired results.
>
I don't know how rece
On Feb 19, 2011, at 4:03 PM, Richard Fairhurst wrote:
> From what I can tell (talk-ca postings etc.) 'sammuell' is a fairly
> inexperienced OSMer who presumably thinks "this is how things are done". It
> isn't. How do we stop this impression taking hold? How do we explain that
> imports are _not
Andrew Errington-2 wrote:
>
> Anyway, I like the idea of using imports as a 'scaffold' for building real
> objects. Imported data could sit on a separate layer, much like GPS
> traces,
> then a mapper can either trace over the imported shapes, or select an
> imported object and 'promote' it
On Feb 19, 2011, at 4:27 PM, Nic Roets wrote:
> On Sun, Feb 20, 2011 at 2:03 AM, Richard Fairhurst
> wrote:
>> This is getting crazy.
>>
>> Exhibit 1:
>> http://twitter.com/#!/maproomblog/status/39053538692698112
>>
>> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
>
On Sat, Feb 19, 2011 at 6:59 AM, Eric Marsden wrote:
> Hi,
>
> I have been experimenting with rendering history flow visualizations of
> Openstreetmap contributors for a region. These charts show the most
> prolific contributors in the region and how their contribution volume
> changed over time.
On 2/19/2011 8:48 PM, Andrew Errington wrote:
Anyway, I like the idea of using imports as a 'scaffold' for building real
objects. Imported data could sit on a separate layer, much like GPS traces,
then a mapper can either trace over the imported shapes, or select an
imported object and 'promote'
I have also encountered situations where an imported road is in the correct
location, but is incorrectly tagged, such as with the name of a street that is
actually a couple of miles away. The imported data may also lack Points Of
Interest, or a given POI may be out of date (for example, I found
On Sun, 20 Feb 2011 10:16:10 Mike N wrote:
> On 2/19/2011 8:04 PM, Andrew Errington wrote:
>
> Imports aren't always bad. Consider the equivalent case of one or
> more mappers who worked heavily in your area 2 years ago. You might
> discover errors and lack of new roads and come to the same con
In Nashville, Tennessee, USA, where I live, most of the existing data came from
the TIGER import (mapping done by census workers). In the areas that I have
checked, about 60% of the data appears to be correct; about 20% needs tweaking
for issues such as one or two streets in a neighborhood bein
I'm offering anyone who wants to take over transiki or glider the chance
to do so, and their domains will auto-expire otherwise. Changing jobs,
continuing OSM work and lack of bandwidth is why.
Transiki.org, a transit wiki got initial buzz and followers on the list
but I've just not had the ti
On 2/19/2011 8:04 PM, Andrew Errington wrote:
> Imports are bad. It's
> bad because I discover errors and start to think 'How many more
errors must
> there be?'. It's mainly bad for two reasons. Firstly, the data is
old, and
> there has been a significant road-building program going on here f
On Sun, 20 Feb 2011 09:40:03 Frederik Ramm wrote:
> Finally, all these warnings must sound hollow to someone who lives in a
> place where 90% of data around him is imported. You will have a hard
> time telling him that imports are bad.
I live in a place where 90% of the data is imported. Imports
Hi,
Richard Fairhurst wrote:
It isn't. How do we stop this impression taking hold? How do we explain
that imports are _not_ welcome except as a last resort, and if you do
them, you _must_ follow a very, very rigorous set of guidelines?
Find out what tools the importers are using. Place very b
On Sun, Feb 20, 2011 at 2:03 AM, Richard Fairhurst wrote:
> This is getting crazy.
>
> Exhibit 1:
> http://twitter.com/#!/maproomblog/status/39053538692698112
>
> "Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
> introduced hundreds of errors. #osm #openstreetmap #whybothe
Hello Nic,
On Sun, 2011-02-20 at 02:01 +0200, Nic Roets wrote:
> On Sun, Feb 20, 2011 at 1:38 AM, Mitja Kleider wrote:
> > I agree it needs some updates. I did not want to spend my time on
> > services that are going to be replaced anyway. I would still prefer
> > integration into osm.org, but am
This is getting crazy.
Exhibit 1:
http://twitter.com/#!/maproomblog/status/39053538692698112
"Whoever imported CanVec in Aylmer, Quebec obliterated hours of work and
introduced hundreds of errors. #osm #openstreetmap #whybother"
Once again, some keyboard jockey has decided that his l337 impor
On Sat, 2011-02-19 at 17:30 +, Richard Mann wrote:
> There's probably some good reason, but why isn't there a link from
> osm.org to report a bug?
I do not know the direct answer to that question. There had been some
efforts to integrate "data bug reports" into the main website [1]. As
far as
Le 19/02/2011 19:27, Dave F. a écrit :
> On 19/02/2011 17:30, Richard Mann wrote:
>> There's probably some good reason, but why isn't there a link from
>> osm.org to report a bug?
>>
>
> Could it be because not many people use it?
>
> I still don't understand why, in a collaborative project, t
On 19 Feb 2011, at 18:27, Dave F. wrote:
> On 19/02/2011 17:30, Richard Mann wrote:
>>
>> There's probably some good reason, but why isn't there a link from
>> osm.org to report a bug?
>
> Could it be because not many people use it?
>
> I still don't understand why, in a collaborative project,
On 19/02/2011 17:30, Richard Mann wrote:
There's probably some good reason, but why isn't there a link from
osm.org to report a bug?
Could it be because not many people use it?
I still don't understand why, in a collaborative project, that osmbugs
is used as a record to get other people to am
There's probably some good reason, but why isn't there a link from
osm.org to report a bug?
At the moment, my advice to a potential reporter would be:
1) use osm.org
2) spot an error
3) use osmbugs.org (and wonder who schokokeks is and why it shows the
whole of Europe)
4) rezoom to the place wher
I must admit that I didn't know that there was a working instance of TRAPI -
I thought it was just a proposal.
I tend to use xapi to get town or city sized chunks of OSM data, without any
clever processing - would TRAPI be better for this than XAPI, or is it
limited to smaller areas?
Graham.
On 1
Patrick Kilian wrote:
Hi,
For simple map calls there is TRAPI[1]. As far as I know, TRAPI performs
much better on map (bbox) queries than either the main-API, XAPI or ROMA (on
equivalent hardware). Rather than using a database, I think it used a
pre-tiled file structure, so that it simple need
Hi,
> For simple map calls there is TRAPI[1]. As far as I know, TRAPI performs
> much better on map (bbox) queries than either the main-API, XAPI or ROMA (on
> equivalent hardware). Rather than using a database, I think it used a
> pre-tiled file structure, so that it simple needs to peace togeth
Nic Roets wrote:
>
> So a good data structure that can answer most map (bbox)
> calls with a single disk seek is what is needed. (Not a debate on the
> best programming language).
>
For simple map calls there is TRAPI[1]. As far as I know, TRAPI performs
much better on map (bbox) queries than
Hi,
I have been experimenting with rendering history flow visualizations of
Openstreetmap contributors for a region. These charts show the most
prolific contributors in the region and how their contribution volume
changed over time.
Some sample visualizations for Paris, London, Berlin, Wien, Toul
Let me just explain what I see as the major performance bottleneck
with and API implementation: Disk seeks. A typical computer can
perform a million calculations while waiting for the disk to fetch a
few bytes. So a good data structure that can answer most map (bbox)
calls with a single disk seek i
Hi,
> Am I missing something here...? People are complaining about how bogged
> down and slow the current service is, so its being re-written in java?
> Is there any language slower or more resource intensive than java? If
> the service isnt designed to be portable (it only runs on one system
>
30 matches
Mail list logo
