On 28 September 2010 23:22, Jo winfi...@gmail.com wrote:
I created 'sub'-relations for parts of bus routes that are used by more
than one line.
I suggest to finally solve the problem this way: we need to insert a new
logical layer between what we map, and what is displayed. This logical
Bus stops should be nodes offset slightly from the way (not nodes on the way).
How relations are handled is partly a problem with the editors.
Potlatch 1.4 users (who can't readily order relation members, and who
find it a pain having an excess of relations on a way), tend to do
2-way relations,
On 29 September 2010 10:31, Richard Mann
richard.mann.westoxf...@googlemail.com wrote:
Lots of
relations is probably conceptually less complicated than child
relations, so I'd probably go for that, editors-allowing.
Can one deal with this in Potlatch, which is the entry-level editor for
On Sat, 25 Sep 2010 18:01:31 +0200, Zoran Jankovic wrote:
Ali, trebalo bi stvarno upitati i nekog pravnog stručnjaka za takve
stvari...
Treba spriječiti bilo kojeg OSM korisnika ako namjerno ili u neznanju
cini stetu OSM projektu unošenjem nedozvoljenih podataka pogotovo u
zemljama u kojima
A cool map of flood risk in Metro Manila
http://images.gmanews.tv/downloads/ncr/
Made for GMA by Wayne Manuel (of G MapMaker fame)
What I like:
- Search by address (not sure how accurate)
- Location of nearest evac centers
Maybe good to add, routing from your address to nearest
Surely we can all agree to differ about whether data imports are a Good Thing
or a Bad Thing. The legal-talk mailing list is not really the place for such
a discussion. Most people will say 'it depends on the particular data being
added' and we could perhaps leave it at that.
What's important
Well said.
- Original Message -
From: legal-talk-boun...@openstreetmap.org
legal-talk-boun...@openstreetmap.org
To: legal-talk@openstreetmap.org legal-talk@openstreetmap.org
Sent: Wed Sep 29 10:01:33 2010
Subject: Re: [OSM-legal-talk] OS Opendata amp;amp; the new license
Surely we can
This belongs back on talk
with a new header.
OSM states that it is a free map, free to edit and free to use
Whether the database should contain imported stuff, traced stuff, or
only personally surveyed stuff is a very big issue and any intent now
to alter the basic rules of inputting should be
Hi,
Kevin Cordina wrote:
What's important is that the licence choice be not used as a stick to enforce
a particular policy about data imports or other aspects of mapping.
And vice versa. I want to import dataset and that's why we cannot use
license is tail-wagging-dog as well.
Bye
Frederik
kevin wrote:
The issue here is a licence has been chosen, that appears incompatible
with current practise
Think you've got your chronology the wrong way round there.
Blog post on moving to ODbL: January 2008. [1]
OS OpenData released: April 2010.
Richard
[1]
On 29/09/10 12:22, Richard Fairhurst wrote:
kevin wrote:
The issue here is a licence has been chosen, that appears incompatible
with current practise
Think you've got your chronology the wrong way round there.
Blog post on moving to ODbL: January 2008. [1]
OS OpenData released:
But since the licence hasn't been implemented yet, surely the final decision on
choice needs to be made now. Practice has clearly changed since 2008.
If the decision was set in stone in 2008 why wasn't there a big warning when
the OS data was released that it was incompatible?
Kevin
That is only true if 100% of the data is removed.
My statement is correct in terms of the data in the database at the time the
new licence is applied. If there is any residual data then the new licence has
to be dictated by the data source licence, otherwise there is a breach of the
source
On 29 September 2010 13:15, ke...@cordina.org.uk wrote:
But since the licence hasn't been implemented yet, surely the final decision
on choice needs to be made now. Practice has clearly changed since 2008.
If the decision was set in stone in 2008 why wasn't there a big warning when
the OS
On 29 September 2010 22:21, Grant Slater openstreet...@firefishy.com wrote:
The legal advice is that OS OpenData _is_ compatible.
Any reason you specifically didn't mention that OS's lawyer refutes that claim?
___
legal-talk mailing list
Ed,
Ed Avis wrote:
And vice versa. I want to import dataset and that's why we cannot use
license is tail-wagging-dog as well.
Are you saying that any argument based on data imports is irrelevant to the
choice of licence?
What, then, would be an admissible reason for not using licence, in
On 29/09/2010 12:22, Richard Fairhurst wrote:
kevin wrote:
The issue here is a licence has been chosen, that appears incompatible
with current practise
Think you've got your chronology the wrong way round there.
Blog post on moving to ODbL: January 2008. [1]
OS OpenData released: April 2010.
On Wed, Sep 29, 2010 at 2:24 PM, Frederik Ramm frede...@remote.org wrote:
In my opinion, the license must be chosen according to what's best for the
project in the long term; short term considerations should not apply.
Admissible reasons for not using license would be, for example,
... that
On 29/09/2010 13:21, Grant Slater wrote:
The legal advice is that OS OpenData _is_ compatible.
My question in the original post couldn't have been clearer so I find it
frustrating that it took this long to answer.
Do you know what date it got recorded in the LWG minutes?
Dave F.
Emilie Laffray emilie.laff...@... writes:
Hello,just a quick note to mention that two different legal entities in very
different places in the world just adopted ODbL as their preferred
licenses:
Thanks for the note. The first of these, DataPlace, seems to want a permissive
attribution-only
On Wed, Sep 29, 2010 at 11:49 AM, Grant Slater
openstreet...@firefishy.com wrote:
Yes our legal council believes CT/ODbL is compatible. The lawyer did
supply a breakdown and reasoning why he believes it is compatible. BUT
the Contributor Terms are currently being revised and will need
further
Hi,
Dave F. wrote:
As I asked you before, will I be able to use this data under the
proposed new regulations?
Why, of course! You will be able to use OS OpenData under the rules they
come under. This is completely independent of OSM. Even if OSM's and
OS's licenses were totally incompatible
On 29/09/2010 13:21, Grant Slater wrote:
The legal advice is that OS OpenData _is_ compatible.
Do you know what date it got recorded in the LWG minutes?
Dave F.
___
legal-talk mailing list
legal-talk@openstreetmap.org
On 29 September 2010 18:34, Dave F. dave...@madasafish.com wrote:
On 29/09/2010 13:21, Grant Slater wrote:
The legal advice is that OS OpenData _is_ compatible.
Do you know what date it got recorded in the LWG minutes?
The message was via email outside the weekly minutes. But it was badly
On 30 September 2010 07:58, Paul Williams pjwde...@googlemail.com wrote:
or contributor loss), but have felt unhappy about such comments as
those quoted above that the OS data doesn't matter and so it doesn't
matter whether the licence is compatible - I and I am sure many other
people find the
On 30 September 2010 06:34, Frederik Ramm frede...@remote.org wrote:
This is about the ODbL being adopted by others, thus showing that it is not
just OSM who believe that it is good.
What about Ed's question, regardless if the information is useful for
OSM or not, could it be imported into OSM?
Different people have different expectations for what data can be added.
Some even add tags for phone numbers. For large public-facing businesses such
as hotels it obviously makes sense to put the full name on the map. For
people's houses it would be crazy to list the occupants (though some OSM
It's great to see the new Mapquest sites up and running. Is there anything that
we the OSM mappers can do to improve them? In other words are there any
particular wishes from the Mapquest people about how the data can be improved?
--
Ed Avis e...@waniasset.com
2010/9/29 Ed Avis e...@waniasset.com:
is somewhere between the two. I guess if it is listed in the phone
directory's
business section under a particular name, then that name can go in OSM.
this is legally not correct, while it might be assumable for most
cases that it will go well. People
Am 29.09.2010 11:21, schrieb M∡rtin Koppenhoefer:
2010/9/29 Ed Avise...@waniasset.com:
is somewhere between the two. I guess if it is listed in the phone directory's
business section under a particular name, then that name can go in OSM.
this is legally not correct, while it might be
M∡rtin Koppenhoefer dieterdreist at gmail.com writes:
I guess if it is listed in the phone directory's
business section under a particular name, then that name can go in OSM.
this is legally not correct,
You may be right; I wasn't thinking of legal reasons (which vary from country
to country)
This belongs back on talk
with a new header.
OSM states that it is a free map, free to edit and free to use
Whether the database should contain imported stuff, traced stuff, or
only personally surveyed stuff is a very big issue and any intent now
to alter the basic rules of inputting should be
Am 29.09.2010 11:50, schrieb Elizabeth Dodd:
This belongs back on talk
with a new header.
OSM states that it is a free map, free to edit and free to use
Whether the database should contain imported stuff, traced stuff, or
only personally surveyed stuff is a very big issue and any intent now
to
On Wed, Sep 29, 2010 at 10:57 AM, Peter Körner osm-li...@mazdermind.de wrote:
Imported data is dead data - there's no one that feels responsible for it.
Imports can kill community and give newcomers the feeling that there's
nothing more to be done. Imports *can* help osm but they can also
Am 29.09.2010 12:26, schrieb Nic Roets:
On Wed, Sep 29, 2010 at 11:57 AM, Peter Körnerosm-li...@mazdermind.de wrote:
Imported data is dead data - there's no one that feels responsible for it.
Imports can kill community and give newcomers the feeling that there's
nothing more to be done.
On Wed, Sep 29, 2010 at 11:57 AM, Peter Körner osm-li...@mazdermind.de wrote:
Am 29.09.2010 11:50, schrieb Elizabeth Dodd:
This belongs back on talk
with a new header.
OSM states that it is a free map, free to edit and free to use
Whether the database should contain imported stuff, traced
I have a set of lat lon coordinates.
On maps.google.com, I just enter that in the search field and click go, and
it shows me that. however, no such feature in OSM. Of course I can edit the
URL to point to lat/lon, but copy pasting a set of coordinates is much
easlier.
anyway to do that in OSM?
On Wed, Sep 29, 2010 at 11:41 AM, Peter Körner osm-li...@mazdermind.dewrote:
If there is a plate with name and phone number then this information is
definitely public available without any restrictions.
That's not true. What you can freely see from the street is not necesseraly
something you
On Wed, 29 Sep 2010 16:08:18 +0530, Tanveer Singh
tanveer1...@gmail.com wrote:
I have a set of lat lon coordinates.
On maps.google.com [1], I just enter that in the search field and
click go, and it shows me that. however, no such feature in OSM. Of
course I can edit the URL to point to
On 29/09/10 10:57, Peter Körner wrote:
Imported data is dead data - there's no one that feels responsible for it.
In the long run, both OSM surveyed data and imported data are dead
data. Over the course of years people come and go. We need to get used
to the idea of maintaining a data set
Hi,
Peter Körner wrote:
Imported data is dead data - there's no one that feels responsible for
it. Imports can kill community and give newcomers the feeling that
there's nothing more to be done. Imports *can* help osm but they can
also *hurt* osm, because osm is about people, not data.
+1
Hi,
Nic Roets wrote:
Imported data is dead data - there's no one that feels responsible for it.
Imports can kill community and give newcomers the feeling that there's
nothing more to be done. Imports *can* help osm but they can also *hurt*
osm, because osm is about people, not data.
Obviously
On 29 September 2010 11:26, Nic Roets nro...@gmail.com wrote:
Obviously there are many exceptions to your rule, like the TIGER import.
TIGER isn't a good example of a successful import.
The TIGER import killed a fledgling community in the US, which is now
only slowly recovering. TIGER has
It wasn't me, but I agree with whoever it was.
I don't agree with your scenario though. Surely the users should come to a
consensus on the requirements of a licence based on data to be covered, and
desired uses of that data, and then a licence selected that permits that.
If the community
2010/9/29 Maarten Deen md...@xs4all.nl:
In OSM it works the same. There is a search box to the left of the
screen, you can enter a lat/lon pair there and the search comes back
with a link to that location.
Doesn't work... at least not for this coordinate: N 52° 03.595 E 004° 16.983
Regards,
Am 29.09.2010 13:12, schrieb Frank Fesevur:
Doesn't work... at least not for this coordinate: N 52° 03.595 E 004° 16.983
This is not lat/lon but Minutes of arc. It seems, Nominatim, our search
engine, is not capable of this.
Peter
___
talk mailing
On Wed, Sep 29, 2010 at 10:58, Frederik Ramm frede...@remote.org wrote:
Peter Körner wrote:
Imported data is dead data - there's no one that feels responsible for it.
Imports can kill community and give newcomers the feeling that there's
nothing more to be done. Imports *can* help osm but
On Wed, Sep 29, 2010 at 11:17, Peter Körner osm-li...@mazdermind.de wrote:
Am 29.09.2010 13:12, schrieb Frank Fesevur:
Doesn't work... at least not for this coordinate: N 52° 03.595 E 004°
16.983
This is not lat/lon but Minutes of arc. It seems, Nominatim, our search
engine, is not capable
On Wed, 29 Sep 2010 13:12:11 +0200, Frank Fesevur
f...@users.sourceforge.net wrote:
2010/9/29 Maarten Deen md...@xs4all.nl:
In OSM it works the same. There is a search box to the left of the
screen, you can enter a lat/lon pair there and the search comes back
with a link to that location.
I feel some clarification on what is meant by import is needed. For
example recently I've been importing names of bays from public
domain maps. I call adding this data from the PD maps to OSM importing
because the data was created somewhere else first, even though I'm
adding it on a case-by-case
Am 29.09.2010 13:47, schrieb Andrew Harvey:
I feel some clarification on what is meant by import is needed. For
example recently I've been importing names of bays from public
domain maps. I call adding this data from the PD maps to OSM importing
because the data was created somewhere else first,
On Wed, Sep 29, 2010 at 12:58 PM, Frederik Ramm frede...@remote.org wrote:
Peter Körner wrote:
Imported data is dead data - there's no one that feels responsible for it.
Imports can kill community and give newcomers the feeling that there's
nothing more to be done. Imports *can* help osm
On Tue, Sep 28, 2010 at 4:41 PM, Niklas Cholmkvist towards...@gmail.com wrote:
Hi list,
On Tue, 2010-09-28 at 15:22 -0400, Richard Weait wrote:
On Tue, Sep 28, 2010 at 2:31 PM, Niklas Cholmkvist
towards...@gmail.com wrote:
SNIP
How do you handle this issue when adding doctors or businesses
On 29.09.2010 13:54, Pieren wrote:
I'm not feeling more responsible for data created by other OSM
contributors than third-party geodata. Both have errors or will be
outdated soon or later.
I think the point is more about contributing in areas almost empty or
in areas almost well mapped
You need to dial a helicopter to get you off the mountain
http://www.dailymail.co.uk/news/worldnews/article-1315762/White-van-man-airlifted-safety-satnav-sends-mountain.html
___
talk mailing list
talk@openstreetmap.org
Peter Wendorff wrote:
The first is creation and you see immediately the
effect on the rendered maps, the second is maintenance and is much
less funny. That's two different types of contributions and two
different public.
The problem exists - of course, and yet it is visible mainly at bit
Hi,
On Wed, 2010-09-29 at 11:21 +0200, M∡rtin Koppenhoefer wrote:
this is legally not correct, while it might be assumable for most
cases that it will go well. People have to agree to be listed in phone
directories, but that doesn't imply that they also want to be listed
on other services
Frederik Ramm frede...@... writes:
What's important is that the licence choice be not used as a stick to enforce
a particular policy about data imports or other aspects of mapping.
And vice versa. I want to import dataset and that's why we cannot use
license is tail-wagging-dog as well.
Are
My view is there are very different requirements in different
countries. Countries such as Australia, US, Canada have much lower
population densities than many European countries. It's just not
practical to rely on people with GPS devices and cycles. Yes there is
tracing from satellite images
On Wed, Sep 29, 2010 at 6:58 AM, Frederik Ramm frede...@remote.org wrote:
Instead of importing data, data should be mixed in at the rendering stage.
It really depends on the data. If the data can be imported in a form
which is already commonly used for non-imported data, I'd say it
should be
- Original Message -
From: Grant Slater openstreet...@firefishy.com
To: ke...@cordina.org.uk; Licensing and other legal discussions.
legal-t...@openstreetmap.org
Sent: Wednesday, September 29, 2010 1:21 PM
Subject: Re: [OSM-legal-talk] OS Opendata amp; the new license
On 29 September
Am 29.09.2010 14:31, schrieb John Smith:
You need to dial a helicopter to get you off the mountain
http://www.dailymail.co.uk/news/worldnews/article-1315762/White-van-man-airlifted-safety-satnav-sends-mountain.html
Selfish satnav just wanted to get better satellite reception.
--
On Wed, Sep 29, 2010 at 13:44, Anthony o...@inbox.org wrote:
Of course, if keeping stuff in sync is practically impossible, a good
import is probably going to have to be manual (if you can't keep stuff
in sync, and the data is in a form which is already commonly used for
non-imported data,
Hello,
just a quick note to mention that two different legal entities in very
different places in the world just adopted ODbL as their preferred licenses:
http://www.dataplace.org/odbl
(sorry it is in French but people who can read will see that it is the city
of Paris)
You need to dial a helicopter to get you off the mountain
http://www.dailymail.co.uk/news/worldnews/article-1315762/White-van-man-airlifted-safety-satnav-sends-mountain.html
I wonder how the OSM data looks on this mountain pass...
___
talk
Just a guess: http://osm.org/go/0Cy6e0oD--
Joseph
On 29 September 2010 15:52, Mike N. nice...@att.net wrote:
You need to dial a helicopter to get you off the mountain
http://www.dailymail.co.uk/news/worldnews/article-1315762/White-van-man-airlifted-safety-satnav-sends-mountain.html
On Wed, 29 Sep 2010 08:36:57 + (UTC)
Ed Avis e...@waniasset.com wrote:
Different people have different expectations for what data can be
added. Some even add tags for phone numbers. For large public-facing
businesses such as hotels it obviously makes sense to put the full
name on the
I've written previously about OSM usability studies, and now it's happening.
Nate Bolt from the fantabulous Bolt|Peters is going to help OSM run usability
tests and we need your help.
The timeline looks something like this: This week or next we're going to switch
on some javascript on the OSM
On 29/09/2010 16:13, SteveC wrote:
On Sep 29, 2010, at 8:15 AM, Dave F. wrote:
On 29/09/2010 12:22, Richard Fairhurst wrote:
kevin wrote:
The issue here is a licence has been chosen, that appears incompatible
with current practise
Think you've got your chronology the wrong way round there.
On Wed, Sep 29, 2010 at 10:38 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Wed, Sep 29, 2010 at 13:44, Anthony o...@inbox.org wrote:
Of course, if keeping stuff in sync is practically impossible, a good
import is probably going to have to be manual (if you can't keep stuff
in sync,
On Wed, Sep 29, 2010 at 11:59 AM, Anthony o...@inbox.org wrote:
I'd say that anyone who can devise a general tool which
can merge all the different foreign databases together has thereby
rendered OSM obsolete.
...at least in any jurisdictions without sweat-of-the-brow. Why
bother with OSM if
On Wed, Sep 29, 2010 at 15:59, Anthony o...@inbox.org wrote:
On Wed, Sep 29, 2010 at 10:38 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Wed, Sep 29, 2010 at 13:44, Anthony o...@inbox.org wrote:
Of course, if keeping stuff in sync is practically impossible, a good
import is probably
We need to think of some simple tasks for new users to complete, and we'll
put them together over on this wiki page. Add a street?
This sort of study will be interesting to see. Adding a street today
must be daunting for the newbie.Despite the lure of the open road -
blank areas where
On Sep 29, 2010, at 9:49 AM, Dave F. wrote:
On 29/09/2010 16:13, SteveC wrote:
On Sep 29, 2010, at 8:15 AM, Dave F. wrote:
On 29/09/2010 12:22, Richard Fairhurst wrote:
kevin wrote:
The issue here is a licence has been chosen, that appears incompatible
with current practise
Think you've
On Wed, Sep 29, 2010 at 12:09 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
I *don't* mean that they could do it *automatically*. Distributed
version control systems don't do that either, you always need a human
to look at the result to see if it's sane.
The problem with imports that
On Wed, 29 Sep 2010 11:53:10 +0100
TimSC mappingli...@sheerman-chase.org.uk wrote:
On 29/09/10 10:57, Peter Körner wrote:
Imported data is dead data - there's no one that feels responsible
for it.
In the long run, both OSM surveyed data and imported data are dead
data. Over the course
fyi,
thats the way we are dealing with the CanVec data for Canada, not data
is blindly dropped in, it's simply carefully merged and added where
its needed. So the overall map is exactly what osm- ccbysa/odbl map
is looking for.
It's not that hard to convert any data into small sized .osm files
On 29 September 2010 16:49, Grant Slater openstreet...@firefishy.com wrote:
Thanks 80n, but those are your words and views.
Where are you quoting these numbered responses from?
I see, minutes from the LWG meeting last night. 2 of 7 LWG members in
attendance. I wasn't on the call as I had an
On Wed, Sep 29, 2010 at 15:34, SteveC st...@asklater.com wrote:
Those people fill out a form and are invited later to use some simple online
screen capturing software while asked to do some simple tasks and this is
where you come in.
What screen capturing software package is it?
On 29 September 2010 18:15, Anthony o...@inbox.org wrote:
On Wed, Sep 29, 2010 at 11:49 AM, Grant Slater
openstreet...@firefishy.com wrote:
Yes our legal council believes CT/ODbL is compatible. The lawyer did
supply a breakdown and reasoning why he believes it is compatible. BUT
the
I was just looking at Amsterdam's Vondelpark in OSM (one of my
favorite places anywhere),
http://ookaboo.com/o/pictures/topic/371522/Vondelpark
and noticed that OSM has very detailed differentiation between bike and
pedestrian paths in the park, something that Google doesn't have.
[Check
On Wed, Sep 29, 2010 at 4:49 PM, Grant Slater
openstreet...@firefishy.comwrote:
On 29 September 2010 15:33, 80n 80n...@gmail.com wrote:
It might greatly reduce the volume on this list if that legal advice
were
published in full.
It would also help if members of the LWG were a little
The day someone tells me that I have to collect signatures from every
business I map is the day I stop contributing to OSM. With all respect
to local laws... that is just plain ridiculous, lawyers be damned.
Where would this archive of signatures even exist? Does OSMF have a
secret bunker under a
On Wed, 29 Sep 2010 13:52:55 +0200
Peter Körner osm-li...@mazdermind.de wrote:
I think this discussion is about
- automated
- big
imports.
There are people who frown on all sorts of methods of data collection.
This discussion should not be restricted to automated or big imports.
I think imports *can* be beneficial, but only when handled in a good,
collaborative way.
Imports should involve:
1) local mappers evaluating the datasets / imports on a case-by-case basis
(is the license acceptable, is the data high quality better than what osm
mappers can do - e.g. building
Hi,
with all the talk about imports recently, I am wondering which countries
have actually _not_ seen any imports so far? I.e. which communities have
chosen to build all their data from traditional surveying and ignored any
other available data sources?
With imports I thereby mean both full
Hi,
Kai Krueger wrote:
With imports I thereby mean both full imports and tracing imports, i.e.
any data that has been copied one way or another over from a third party
source.
Including aerial imagery? Including stuff traced from Landsat?
Currently all of the active countries I can think of
On Wed, Sep 29, 2010 at 1:02 PM, Grant Slater
openstreet...@firefishy.com wrote:
On 29 September 2010 11:26, Nic Roets nro...@gmail.com wrote:
Obviously there are many exceptions to your rule, like the TIGER import.
Nic, local example... Durban South Africa, we imported a dataset, the
few
On 29/09/10 22:58, Frederik Ramm wrote:
Hi,
Kai Krueger wrote:
With imports I thereby mean both full imports and tracing imports, i.e.
any data that has been copied one way or another over from a third party
source.
Including aerial imagery? Including stuff traced from Landsat?
Let's leave
Hi,
Kai Krueger wrote:
Yes, more or less. Given that some people seem to be strongly arguing
that the use of third party data is crap, mindless and harmful,
... among them myself, as you probably have noticed ...
I would like to get a feel for how bad the situation is and where there
are
Well if you are willing to wait a week or two, I might be able to shed
some light on the issue.
I decided to take a cartography course this semester. One of our
projects is to create a thematic map of our choosing and I was hoping
to make one related to OSM. I just started playing with osmosis
On Wed, Sep 29, 2010 at 6:47 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
Kai Krueger wrote:
Yes, more or less. Given that some people seem to be strongly arguing that
the use of third party data is crap, mindless and harmful,
... among them myself, as you probably have noticed ...
On Wed, Sep 29, 2010 at 11:41 PM, Kai Krueger kakrue...@gmail.com wrote:
with all the talk about imports recently, I am wondering which countries
have actually _not_ seen any imports so far? I.e. which communities have
chosen to build all their data from traditional surveying and ignored any
On Wed, Sep 29, 2010 at 6:47 PM, Frederik Ramm frede...@remote.org wrote:
PS: I don't think the US is going to be a wasteland in terms of OSM
community forever. I just think that without the TIGER import they'd have
less data but much more community today.
I think the relative lack of OSM
Yeah the physical spread of people out here in the middle part of the
country is pretty sparse and I think a lot of people don't quite get
that. There is a good chunk of Kansas where the population density is
5 people per square mile or less. And those 5 people have absolutely
no use for maps
On Wed, Sep 29, 2010 at 7:57 PM, Peter Körner osm-li...@mazdermind.de wrote:
Imported data is dead data - there's no one that feels responsible for it.
Imports can kill community and give newcomers the feeling that there's
nothing more to be done. Imports *can* help osm but they can also *hurt*
On 30 September 2010 10:16, Anthony o...@inbox.org wrote:
I also think treating the US as though it's a single state (e.g.
comparing it to say Germany), is not all that useful.
Australia is worst, similar size, but much much much less people, and
Frederick seemed to think you could map out most
On 30 September 2010 13:28, Steve Bennett stevag...@gmail.com wrote:
- the imported data is small enough to be manually merged, but high
quality enough to make it worthwhile
I imported state roads in Qld some time ago, I selectively copied
missing roads, especially in more remote areas that
On Wed, Sep 29, 2010 at 11:28 PM, Steve Bennett stevag...@gmail.com wrote:
IMHO imports are at the best in these cases:
- the data cannot be obtained by surveying (eg, administrative boundaries)
Wow, really? I'd say that's the worst time to do an import. Why
import it if you can't edit it,
On 30 September 2010 13:58, Anthony o...@inbox.org wrote:
On Wed, Sep 29, 2010 at 11:28 PM, Steve Bennett stevag...@gmail.com wrote:
IMHO imports are at the best in these cases:
- the data cannot be obtained by surveying (eg, administrative boundaries)
Wow, really? I'd say that's the worst
1 - 100 di 272 matches
Mail list logo
