Russ,
(I'm trying to move this over to legal-talk because you are
expressing an interesting legal viewpoint):
On 05/05/11 06:27, Russ Nelson wrote:
I'm wondering on what data you come to that conclusion? Because people
have clicked "ok" on the license change and CTs? And yet there is no
ag
Maarten Deen wrote:
> > Nominatim use them (boundariy relations) efficiently.
>
> The lookup may be efficient, it is frequently wrong and again dependent
> of correct and complete admin_levels.
> Currently it places every street where I live (in the Netherlands) in
> Belgium and does not spe
2011/5/5 Russ Nelson :
> Dermot McNally writes:
> > The change in licence and CTs has been endorsed massively by The
> > Community.
>
> I'm wondering on what data you come to that conclusion? Because people
> have clicked "ok" on the license change and CTs? And yet there is no
> agreement and no
On Wed, May 4, 2011 at 6:41 PM, Serge Wroclawski wrote:
> On Wed, May 4, 2011 at 2:07 AM, Frederik Ramm wrote:
> I've thought about this myself; would it be better to have separate,
> smaller instances of OSM, the way Wikipedia does.
I think it would make sense to have many layers of data, each
Dermot McNally writes:
> The change in licence and CTs has been endorsed massively by The
> Community.
I'm wondering on what data you come to that conclusion? Because people
have clicked "ok" on the license change and CTs? And yet there is no
agreement and no contract. The OSMF has made it clear
Hi,
On 05/04/11 19:34, Kai Krueger wrote:
Wikipedia has a global foundation responsible for the maintenance of all
databases and then local chapters who provide further support and services
on top of that.
OSM (can) works similar. There is a global database and various local
chapters that provi
I think OSM can be great, but it still has a very long way to go.
Let's look at some of the best open source projects:
1. Linux: Dominates the server market and will soon dominate the
smartphone market.
2. Apache: Dominates web servers.
3. Firefox: For a very long time they were miles ahead of the
On 4 May 2011 18:21, Nic Roets wrote:
> I rejected the CTs because I felt the OSMF* was out of touch with the
> community. Your statement just reaffirms that.
The Community, by my definition, is made up of the people who map,
most of whom are not members of OSMF. The change in licence and CTs
ha
Serge Wroclawski-2 wrote:
>
> I've thought about this myself; would it be better to have separate,
> smaller instances of OSM, the way Wikipedia does.
>
Arguably that is already the case.
Wikipedia has a global foundation responsible for the maintenance of all
databases and then local chapters
Oh and I missed the second half - what makes you think we appointed the
sysadmins?
On 5/4/2011 10:23 AM, Steve Coast wrote:
So you're suggesting OSM is one of the worst project?
On 5/4/2011 10:21 AM, Nic Roets wrote:
On Wed, May 4, 2011 at 7:02 PM, Steve Coast wrote:
... one of the best ope
So you're suggesting OSM is one of the worst project?
On 5/4/2011 10:21 AM, Nic Roets wrote:
On Wed, May 4, 2011 at 7:02 PM, Steve Coast wrote:
... one of the best open source projects.
I rejected the CTs because I felt the OSMF* was out of touch with the
community. Your statement just reaff
On Wed, May 4, 2011 at 7:02 PM, Steve Coast wrote:
> ... one of the best open source projects.
>
I rejected the CTs because I felt the OSMF* was out of touch with the
community. Your statement just reaffirms that.
*: I make no distinction between the board and the people they appoint
e.g. the sy
I think that has been done with the change to the Contribution Terms and
licensing.
Cheerio John
On 4 May 2011 13:02, Steve Coast wrote:
> I can't, but that wasn't clear to me. It's also dominant in air traffic
> control. It seems a little flimsy as a base reason to break up one of the
> best o
I can't, but that wasn't clear to me. It's also dominant in air traffic
control. It seems a little flimsy as a base reason to break up one of
the best open source projects.
On 5/4/2011 10:01 AM, Nic Roets wrote:
On Wed, May 4, 2011 at 6:46 PM, Steve Coast wrote:
I dispute point 1, if anythi
On Wed, May 4, 2011 at 6:46 PM, Steve Coast wrote:
> I dispute point 1, if anything the project is German-centric if you look at
> the depth and quantity of data?
Steve, he was talking about language, not geographical dominance. You
can't argue that English is dominant.
_
I dispute point 1, if anything the project is German-centric if you look
at the depth and quantity of data?
On 5/4/2011 9:41 AM, Serge Wroclawski wrote:
On Wed, May 4, 2011 at 2:07 AM, Frederik Ramm wrote:
Hi,
On 05/04/11 03:23, Serge Wroclawski wrote:
Dave, if you have a suggestion that
On Wed, May 4, 2011 at 2:07 AM, Frederik Ramm wrote:
> Hi,
>
> On 05/04/11 03:23, Serge Wroclawski wrote:
>>
>> Dave, if you have a suggestion that would let us communicate in real
>> time (not over weeks via email) then please share this with the group.
>
> The alternative to communicating in rea
2011/5/4 Jaak Laineste :
> Regarding user interface: I would add "quick street selector" feature
> to JOSM (and other editors)
a workaround to improve usability would be to enable autocompletion of
addr:street with the values of the name-keys of the highways.
cheers,
Martin
https://josm.openstr
On 5/4/2011 7:58 AM, Jaak Laineste wrote:
Regarding user interface: I would add "quick street selector" feature
to JOSM (and other editors) - when you open Preset>Annotations>Address
screen, then instead of text field it would have buttons to select
quickly up to 5 nearest streetnames. I would pr
2011/5/4 Maarten Deen :
> On Wed, 4 May 2011 08:07:07 +0200, pdora...@mac.com (Pierre-Alain Dorange)
> wrote:
>>
>> Felix Hartmann wrote:
>>
>>> Nope, it makes sense all the time. Cause boundaries really are not ment
>>> for deducting information onto what's inside. This really slows down any
>>>
Why not setup a "Wave" server, using google Wave software. It's open
source, and really efficient for real time as well as non real time
communication. Alternative a google server could be used, but then it is
just like other proprietary tools (though based on opensource software).
___
Frederik Ramm schrieb:
>Hi,
>
>Matthias Julius wrote:
>> One option would be to run osmosis with clipIncompleteEntities=false
>> (the default). That would not increase the burden on your box and
>still
>> allow the extracts to be merged. Of course, this would leave it up
>to
>> the data cons
Hello!
> Dave, if you have a suggestion that would let us communicate in real
> time (not over weeks via email) then please share this with the group.
I have another suggestion: learn how to use e-mail efficiently :-)
An e-mail discussion need not take weeks if all interested people respond
at l
23 matches
Mail list logo
