On Fri, May 21, 2010 at 6:34 AM, M∡rtin Koppenhoefer
wrote:
>
>> One problem I have with the concept of "access=destination", even beyond the
>> fact that it says "right of access", is that parking lots quite often aren't
>> connected to the places they serve. Something like access=customer is
>>
2010/5/20 Tyler Gunn :
> Lol, now just think if we micro-mapped each tree in the parking lot you
> could get your GPS to determine the spot that is likely to be in shade for
> a large part of the day, keeping your car nice and cool! :) Ok, too far
> perhaps.
height and diameter are still missing
2010/5/19 Anthony :
> One problem I have with the concept of "access=destination", even beyond the
> fact that it says "right of access", is that parking lots quite often aren't
> connected to the places they serve. Something like access=customer is
> therefore *more general*. The parking lot mig
On Thu, May 20, 2010 at 8:50 AM, John Smith wrote:
> On 20 May 2010 22:46, Tyler Gunn wrote:
> > Lol, now just think if we micro-mapped each tree in the parking lot you
> > could get your GPS to determine the spot that is likely to be in shade
> for
> > a large part of the day, keeping your car n
On 20 May 2010 22:46, Tyler Gunn wrote:
> Lol, now just think if we micro-mapped each tree in the parking lot you
> could get your GPS to determine the spot that is likely to be in shade for
> a large part of the day, keeping your car nice and cool! :) Ok, too far
> perhaps.
Some people do map i
> Rather than permitted=*, why not use parking_use=*? That would then be
> consistent with your proposed relation. Though "permitted" is more
> general and might be able to be generalised to other features...
Or perhaps something like "permitted_parkers"; I don't think there's
anything wrong with
> Agreed, although the situations in which it's not so clear are the ones
> where OSM could really get an advantage over the competition. So many
> times
> I'm directed by Google Maps to a location quite a distance away from the
> parking lot I'm trying to get to. It's especially annoying when t
On 20 May 2010 20:44, Jean-Guilhem Cailton wrote:
> Compared with the monitoring sites with other purposes (nice aircraft
> noise tracking site by the way), I thought that at least for the
It tracks aircraft too :)
> positioning systems monitoring sites, precise lat/lon should be available.
The
Le 20/05/2010 06:29, John Smith a écrit :
> Here's a sample generated from NASA site log files:
>
>
>
>
>
>
>
>
>
>
>
> v='http://igscb.jpl.nasa.gov/igscb/station/log/bucu_20100503.log' />
>
>
> Just to make things more interesting, the lat/lon given for some/all
> sites are in country
No changes during RFC phase. The voting on the seafood shop is now open:
http://wiki.openstreetmap.org/wiki/Proposed_features/seafood_shop
Claudius
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_stop_line
On -10/01/37 20:59, John Smith wrote:
> On 20 May 2010 18:45, Alex Wardle wrote:
>> Feature Proposal - RFC - Advanced stop line
>
> URL?
>
>
___
Tagging mailing list
Tagging@ope
On 20 May 2010 18:45, Alex Wardle wrote:
> Feature Proposal - RFC - Advanced stop line
URL?
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Feature Proposal - RFC - Advanced stop line
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
13 matches
Mail list logo
