[OSM-talk] Lake Nasser not rendering

[Peter Dörrie]

Hi,

what is the reason, that lake nasser in upper egypt is not rendering in
Mapnik?
http://www.openstreetmap.org/?lat=23.96481&lon=32.88516&zoom=15&layers=B000FTF

There is new yahoo imagery available and I would like to refiine the lake,
but would prefer solving the rende problem beforehand.

Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Planning a trekking holiday online

[Peter Dörrie]

Hi everybody,

I would like to plan my next trekking holiday with online tools. What I have
in mind is the following: A map (preferably osm) to mark tours and routes
and some form of note taking tool to pull together information on
accommodation, supplies, flights and so forth.

Does anybody know such a service in the www?

Thanks,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] maxheight/height

[Peter Dörrie]

On Mon, Jul 27, 2009 at 11:31 AM, Aun Johnsen (via Webmail) <
skipp...@gimnechiske.org> wrote:

> maxheight=* refers to legal maxheight, in some countries, such as brazil,
> there is a difference on legal height (restriction) and physical
> height/clearance (information sign). See my note on the discussion on the
> wiki key:height - if height is not to be used for this, than another tag is
> needed
>
> -


in Germany you will often find "height above sea level" written on signs for
Motorway-Bridges so height=* is not very clear. I think it would be better
to attach this information to the street, not to the bridge because it is
the street that is influenced by this. and you could argue that in those
cases the "legal" height is identical with the "physical" height.

Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] amenity=parking, time limit tag?

[Peter Dörrie]

>I see a problem wiith this idea. Only because councils change the
times/prices reguarly. Often without notice. You can use many >supermarket
car parks for 2 hours but that could change depening on the seasons

But it should be tagged nonetheless. The fact that there is a time
limitation for parking is more important than the exact duration of that
limitation. So maybe something like

time_limitation=yes
limitation_duration=3 (time in hours)

Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Move the Map

[Peter Dörrie]

> I disagree because I think, the map is the best way to show our
> potential


Well, clearly not. The potential of OSM is not that we can produce a nice
slippy map. Google did that just fine. The potential is that you can do a
lot more with the osm data, than you can with any copyrighted map-API from
one of the big guys. So if we want to show off our potential, then we should
not present our slippy map, but cool projects that have been realised with
osm data.


> (and is also used to serve access to
> online(potlatch-)editors and to export data).


As I said, it is a tool (in a very positive sense).


> Some more features
> wouldn't harm though, if inserted into the common interface without
> any cluttering (e.g. "intelligent" search, GUI for adding markers in
> permalinks, etc.).
>

I am with you here. I think those should be implemented in any case.

Greetings,

Peter


>
> Martin
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Move the Map

[Peter Dörrie]

> Ah yeah, those were the days when we didn't have a reliably working
> map on the front page, so we were looking for alternatives (you can
> just make out the map image is the old linework-on-landsat version.
> But that's not an issue any more.
>

Well, but it is an issue that the map we show off now, is not exactly
feature rich (plain text: is nothing to show off). So I think the discussion
is warranted to either add more bliing bling to the map, or give it a less
dominant status.


I personally prefer the second approach. The map on osm.org is mainly a
working tool. It is not shiny, but it has a purpose and it does itss job
well. So we should present it that way and give the "first row advantage" to
those shiny feature-laden applications that serve well to impress and
convince new people of OSM.


Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Move the Map

[Peter Dörrie]

Hi all,

there has been a quite lively debate on talk-de about the appearance of the
openstreetmap.org page to "newcomers" to the project, speaking people who
heard of it for the first time and come around to see if they (and how) they
will be able to use it for their goals (note: not all of them might want to
participate in mapping). Several people made some suggestions and I would
like to get your take on those:

Move the map

It was argued that the map itself does not provide enough "eye candy" and
usability (ability to draw on it, etc.) for first time visitors. Others
argued (and I support that) that neat functions (routing, drawing, etc) are
not the goal of openstreetmap.org. OSM exists to provide the data, not the
services.
But then, why give the map a such dominant position? The suggestion has been
made to move the map (or make it less dominant), and instead offer a set of
high profile real life OSM applications (OpenCycleMap, OpenRouteService,
Cloudmade, etc.)

Greetings,

Peter

PS: I didn't participate in the discussion myself, but I think it touches
some important points which can not be changed without the consensus of not
only the German community.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] putting GPS units in taxis

[Peter Dörrie]

Another option is not having the GPRS and just dump the GPX data once you
> get back the device.
>

+1

That would be my personal recommendation. I once made a small research on
the availability of GPRS enabled devices (out f personal interest) and came
to the conclusion that they tend to be very expensive for what they do.

So I would suggest:

Buy some good quality gpx trackers, that allow for programming that swiches
tracking of, if the device doesn't move (so if the taxi sits in the parking
lot for a night, it doesn't collect loads of random points) and has a good
battery life. Then just get the tracks every couple of days.

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] How to get into the planet

[Peter Dörrie]

Hi,

how can I get my blog  into the OSM planet (
blogs.openstreetmap.org)? Are there any requirements for a blog to be
included?

Thanks,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] A lot of Spam on the user diaries

[Peter Dörrie]

Hi,

lately there has been a lot of spam in the user dieary entries (and
therefore in the planet as well). And I found no way to "flag" those users
or entries for an admin to investigate this. So please

1. block the following accounts:

Accessories 
Vitamins 
ericola 


2. Implement a "flag" button in the user diaries, so that that spam can get
countered effectively
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Cheat Sheet

[Peter Dörrie]

Hi everybody,

I recently came across the idea of producing a "cheat sheet" of the Map
Features page for mappers to take "into the field". I hink that this is a
great idea and I have set up a wiki page (
http://wiki.openstreetmap.org/wiki/Cheat_sheet) to discuss and refine a
concept for something like this. The goal of the project would be to produce
high quality and highly portable cheat sheets for the OSM community to
facilitate the usage of the ever expanding amount of tags. Please
participate.

Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wanted feature for API 0.7 ??

[Peter Dörrie]

2009/6/8 Frederik Ramm 

> Hi,
>
> Peter Dörrie wrote:
>
>> The current renderes wouldn't be able to handle it either and forcing 50+
>> applications to change would be unappropriate.
>>
>
> Why, we're doing that all the time ;-)


Yeah I thought so too, but this was one of the main arguments against my
first try to establish something like this.


>
> There are many unsolved questions here. For example: What happens if parts
> of the "ancient" world transcend your "fourth dimension", e.g. a
> contemporary secondary road uses a few bits of an ancient Roman road. They
> would surely share the same nodes, wouldn't they? But if someone then
> deletes the secondary road (which he downloaded without ever knowing that
> the Roman road also exists because that was shielded from him), he must not
> delete the nodes because they are still used by other objects...


My angle on this is primarily the historical-genetic one. Taking your
example:

1. Brutus Mappus maps this roman long distance road in 100 B.C he tags it
correctly with highway=roman and surface=cobblestone. The road is used in
that form for the better part of the next two millennia.

2. In the 19th century it gets some heavy usage and deteriorates. The local
government decides to build a new road, which uses some of the same vectors
the roman road used so far. The grat-great-great (etc) son of Mappus (John
Maps) splits the road, tagging part of it as highway=disused and others as
highway=construction.

3. The new highway is ready and John tags it as highway=primary

4. The same thing happens several times over until fake Steve finds a
motorway, using some parts of the primary road, using some parts of the
roman road (which by now is not longer visible in the landscape and has been
tagged as historic).

Okay, what does this mean for whom?

Users: The normal user will see a rendering which shows "what is on the
ground". -> Motorway and those parts of the primary road that still exist

Mappers: The normal mapper will see, what is relevant to him. -> Same as
user and some additional tags (oneway, surface, maxspeed, etc.) plus perhaps
those "disused" roads, as they may still be relevant to mapping.

Special interest person (scientist, etc): He gets the possibility of seeing
exactly what he wants to see. The situation in 100 B.C? no problem. Ask the
database about all disused / historic / etc objects? also no problem.

Different object sharing the same nodes over time (and changing them) is not
a problem.



Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wanted feature for API 0.7 ??

[Peter Dörrie]

>
> as frederik says, it doesn't need to be implemented in the API - all
> of it can already be done client-side using the appropriate tags*.


Well several Users made the point that this would "break" all applications
that exist today, as they would be useless in their current state. The
current JOSM for example would not be able to make out the difference
between "planned" , "constructed", "live", "disused" and "historic" objects,
leading to a cluttering of the interface and inflation of the data-amounts.
The current renderes wouldn't be able to handle it either and forcing 50+
applications to change would be unappropriate.

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wanted feature for API 0.7 ??

[Peter Dörrie]

Whatever you say. I dont have the hacking chops needed to fully understand
the APi and how it works. But I am really interested in seeing some form of
"lifespan feature" implemented in OSM. So it would be grate if this
discussion makes some progress in getting closer to that goal.

Greetings, Peter

2009/6/8 Frederik Ramm 

> Hi,
>
> Peter Dörrie wrote:
>
>> in the (albeit short) discussion concerning my proposal to introduce tags
>> for feature lifecylcles (
>>
>> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/4th_Dimension/Archive
>> )
>> the outcome was that it has to be included server-side.
>>
>
> Some kind of general, improved filtering server-side makes sense (for
> example using a few standard tags and then, for example, have editors
> generally request only objects that do not have an "ancient" tag or so ;-)
>
> But the kind of logic that was suggested here, where the API filters by
> itself and when a "delete" request is issued, instead modifies some tags, is
> certainly not the way to go.
>
> Bye
> Frederik
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Overhauled the Garmin page

[Peter Dörrie]

Hi everybody,

I made an overhaul of the Garmin-Page [1] and moved all the different device
series to their own subpages. I also introduced a proposal for an overview
table for individual devices. Please feel free to comment and change
everything.

Peter

[1] http://wiki.openstreetmap.org/wiki/Garmin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] 3D Map Print

[Peter Dörrie]

Hi,

I just saw the blog entry on
http://freegeographytools.com/2009/solid-3d-landscape-models-from-landprintabout
buying a 3D Map-Print. Does anybody know if there is a service out
there that does this with OSM Data?

Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: New Proposed Feature: Tagging the age and duration of existence of features

[Peter Dörrie]

-- Forwarded message --
From: Peter Dörrie 
Date: 2009/5/22
Subject: Re: [OSM-talk] New Proposed Feature: Tagging the age and duration
of existence of features
To: Lester Caine 


 The problem comes with 'end_date', and since in some areas roads ARE
> being destroyed, are they removed from the map or CAN they be left with
> an end_date and features which have an end_date earlier than the current
> date are ignored? ( I'm thinking of the 2012 Olympic site which has
> re-routed many roads? )


I think that tagging a feature with end_date (or existed_till) should by
default have the same effect as deleting it. It vanishes from potlach etc.
But you should have an option in every editor to show features tagged with
end_date. end_date would also only apply to features that at one point
really did exist. Errors in the map should be deleted as usual.

>
>
> The actual content of a date is a major point of discussion, but for the
> time being I would propose sticking with a simple ISO date format. The
> discussion on historic date formats has been going on for years now on
> the genealogical lists without agreement. Just consider where a
> start_date is between two known dates. i.e. a feature is absent on a map
> of 1945 but present in the 1955 map - so you end up with a more complex
> start_date entry ... and which calendar was used to provide the date ;)


To keep things simple I would suggest that if you do not now the exact date,
than you should interpolate. So if a feature was build somwhere between 1600
and 1650 than it is probably good to tag it with 1625. If more detailed
information becomes available, you can come back to it at a later point.
Also, I think that the "western" date system should apply to OSM. All other
calendars can be quite easily  converted.

( start_date and end_date were I think added for things like festivals
> and other transitory map information, so it may be appropriate to
> redefine them as constructed_date and demolished_date to distinguish
> historic data from transitory data ? )



I also think that start_date and end_date are not the best description for
the construction/destruction of a feature.



>
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] New Proposed Feature: Tagging the age and duration of existence of features

[Peter Dörrie]

Hi everybody,

I made a proposal for tagging "the 4th dimension". Hope you like it ;)

http://wiki.openstreetmap.org/wiki/Proposed_features/4th_Dimension

Greetings,

Peter
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk