2009/6/11 hanoj :
>>>
>>> I have idea about relative positioned node on the line (crossing,
>>> bus_stop, railway stops) object with no direct relation to geometry,
>>> but with topology relation.
>>
>> Currently I describe it even in a step further.
>>
>> Imagine that you could contraint lines bas
>>
>> I have idea about relative positioned node on the line (crossing,
>> bus_stop, railway stops) object with no direct relation to geometry,
>> but with topology relation.
>
> Currently I describe it even in a step further.
>
> Imagine that you could contraint lines based on these properties; fo
hanoj wrote:
> I have idea about relative positioned node on the line (crossing,
> bus_stop, railway stops) object with no direct relation to geometry,
> but with topology relation.
Currently I describe it even in a step further.
Imagine that you could contraint lines based on these properties; f
blowing, some people look for shelter. Others
build windmills.
-- Ancient Chinese Proverb.
http://donaldallwright.blogspot.com
From: hanoj
To: talk@openstreetmap.org
Sent: Wednesday, 10 June, 2009 9:04:44
Subject: Re: [OSM-talk] Wanted feature for API 0.7
Hi!
I have idea about relative positioned node on the line (crossing,
bus_stop, railway stops) object with no direct relation to geometry,
but with topology relation.
Legend:
x node
o relative node
way
IDEA object model:
x--o--o-ox
API <0.7
x-- x-
2009/6/9 Nop :
>
> Hi!
>
> Dave Stubbs schrieb:
>>
>> Which just tells you those aren't the "appropriate tags" of which matt
>> speaks.
>>
>> Careful selection of tags means that nothing existing needs to change,
>> unless it's to make life easier for the user by adding filtering
>> features.
>
> T
Hi,
Martin Koppenhoefer wrote:
> I guess you are talking about the pantheon (the parthenon is in Athens)
What an embarassment ;-) you're right of course. I was thinking of Rome
not Greece.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
__
2009/6/8 Frederik Ramm :
> I was actually trying to suggest that it might, in some cases, really
> make sense for things to be shared between the then and the now. If you
> take the Parthenon in Rome, then the geometry should be pretty much the
> same between now and ancient times, and as you say,
On Tue, Jun 9, 2009 at 2:08 AM, Frederik Ramm wrote:
> I was actually trying to suggest that it might, in some cases, really
> make sense for things to be shared between the then and the now. If you
> take the Parthenon in Rome, then the geometry should be pretty much the
> same between now and
> But it opens a large can of worms if you are looking at
> temporal
> information. All SciFi books can tell you that.
What, like a child node might risk becoming it's own grandfather
node?
Ed
___
talk mailing list
talk@openstreetmap.org
http://lists
On Mon, Jun 8, 2009 at 7:08 PM, Frederik Ramm wrote:
> I guess this has the potential to be hellishly complex but also fun.
i guess we've just got different ideas of what "fun" is... i agree
about the hellish part, though ;-)
cheers,
matt
___
talk mai
Hi,
Matt Amos wrote:
> 3) not sharing information which should be shared. if i went to a
> roman road and surveyed it extremely accurately and, because its a
> currently-in-use road, lined up the current highway with the
> measurements that would update the "special interest" roman road,
> right?
2009/6/8 Peter Dörrie :
> 2009/6/8 Frederik Ramm
>> 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
On Mon, Jun 8, 2009 at 3:17 PM, MP wrote:
> I thought of another wanter feature for 0.7 API
>
> Retrieving deleted objects, similarly like it is done in potlatch.
> Currently only potlatch can do this and since potlatch does not work
> well with larger areas (it is way too slow) and does not suppor
Frederik Ramm wrote:
> 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 ;-)
>
> There are many unsolved questions here. For example: What happens if
>
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 again
MP wrote:
> Currently only potlatch can do this and since potlatch does not
> work well with larger areas (it is way too slow) and does not
> support many features that JOSM have (WMS, plugins,
> loading/saving to disk, gpx tracks, gpx waypoints )
Well, apart from the GPX tracks (which it
I thought of another wanter feature for 0.7 API
Retrieving deleted objects, similarly like it is done in potlatch.
Currently only potlatch can do this and since potlatch does not work
well with larger areas (it is way too slow) and does not support many
features that JOSM have (WMS, plugins, loadi
2009/6/8 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 t
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 ;-)
There are many unsolved questions here. For example: What happens if
parts of the "ancient" world transcend
>
> 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 J
2009/6/8 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
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
Hi,
ce-test, qualified testing bv - Gert Gremmen wrote:
> I want to suggest the following feature to the next API :
The API must be kept simple. I agree that lifecycle support needs
improvement but the API is not the place to implement such specific
rules. The API is, and should remain, first a
24 matches
Mail list logo
