For those of you using the shp-to-osm app, I just uploaded the 0.6 version.
If you're looking for what changed, here's the changelog:
http://redmine.yellowbkpk.com/versions/show/15
Download here:
http://redmine.yellowbkpk.com/projects/list_files/geo
___
2009/9/20 Anthony :
> That's an editor issue. If the editor wants to display lanes in a single
> way as parallel ways, and let you edit them if need be, it can do that.
It's also a DB/framework issue, I don't think relations should be
abused for this purpose, instead the DB needs to be extended
On Sat, Sep 19, 2009 at 11:37 PM, John Smith wrote:
> 2009/9/20 Anthony :
> > This can be done without resorting to mapping each lane separately. If
> you
> > have a three lane road with no lane change restrictions or physical
> > barriers, you map it as one way, with three lanes, with the positi
On Sun, Sep 20, 2009 at 1:37 PM, John Smith wrote:
>
> I wasn't suggesting to map each lane separately, however an editor
> could display lanes and it would be so much better to display them as
> parallel ways which could be edited if they needed to be.
John, do you concede that there are some si
2009/9/20 Lennard :
> Not just countries, but also states (different shields per state, for
> instance). Granted: same thing really.
This is one reason to do these sorts of routes as relations instead of
trying to cram lots of information into the way, you then should avoid
overlapping shields if
2009/9/20 Martijn van Oosterhout :
> I suppose it would be possible to get osm2pgsql to assign columns
> based on country locations, if the relevant polygons were available in
> another table. Handling diffs is not the problem, osm2pgsql knows
> exactly which things have changed and can do the rel
2009/9/20 Anthony :
> This can be done without resorting to mapping each lane separately. If you
> have a three lane road with no lane change restrictions or physical
> barriers, you map it as one way, with three lanes, with the position as the
> center of the three lanes. When the road goes to t
On Sat, Sep 19, 2009 at 8:39 AM, Martin Koppenhoefer wrote:
>
> There is indeed a problem with bridges (in cases like yours it looks
> like several bridges where in reality there is just one, then there
> are bridge-names that can differ from the streetname, etc.)
>
I wonder if this perhaps isn't
Hi,
Roy Wallace wrote:
> Regarding search - ideally, I think the user should be able to say
> that they want "to eat a t-bone steak in mood lighting for under $20
> less than 30min drive away"
Whoa, that would be the killer app! "Go out for cheap drinks with some
friends, meet a nice person of t
On Sun, Sep 20, 2009 at 1:43 AM, Martin Koppenhoefer
wrote:
>
> yes, but that's not the problem: straight parallel ways. The problem
> arises when they change (become one more or less), on intersections,
> etc. Try to imagine a situation like the one I posted above in a
> geometrically reduced sys
On Sat, Sep 19, 2009 at 10:27 PM, Greg Troxel wrote:
>
> There's a far larger issue, which I noticed on Garmin's proprietary map
> data. When searching for A, how does one map the desire A to the
> category scheme, and then enter it, and get the right answer? For
> restaurants, is it "American"
On Sat, Sep 19, 2009 at 4:43 PM, Anthony wrote:
> Perhaps there could be some sort of special designation for a way with 3
> lanes at the beginning and 2 lanes at the end, which designates whether the
> right or left lane ends, if you really want to get into the fine detail.
>
To clarify, at the
On Sat, Sep 19, 2009 at 11:43 AM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:
> yes, but that's not the problem: straight parallel ways. The problem
> arises when they change (become one more or less), on intersections,
> etc. Try to imagine a situation like the one I posted above in a
>
On Sat, Sep 19, 2009 at 9:24 AM, John Smith wrote:
> 2009/9/19 Martin Koppenhoefer :
> > don't get you. Isn't "mapping lanes" just the same like what I
> > suggested? I'm in favour of mapping all lanes and ways as well, but
> > you DO need relations to combine them into streets (indicating kind of
this is a lane issue and needs to
> be solved on a lane basis, not on a way basis.
+1, that's what I say.
cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Martijn van Oosterhout wrote:
> I suppose it would be possible to get osm2pgsql to assign columns
> based on country locations, if the relevant polygons were available in
Not just countries, but also states (different shields per state, for
instance). Granted: same thing really.
>> One more iss
El Sábado, 19 de Septiembre de 2009, John Smith escribió:
> I don't see the problem, you just need to be able to tag which lanes
> merge into which, or which diverge, this is a lane issue and needs to
> be solved on a lane basis, not on a way basis.
Per-lane speed limits, per-lane traffic access r
On Wed, Sep 16, 2009 at 4:46 PM, Lennard wrote:
> OTOH, if osm2pgsql will only run some queries and let postgis handle the
> stamping of features with a proper field to filter on in the stylesheet,
> it can be done at the end of the import. The challenge to this method is
> in how to handle diffs.
2009/9/20 Martin Koppenhoefer :
> yes, but that's not the problem: straight parallel ways. The problem
> arises when they change (become one more or less), on intersections,
> etc. Try to imagine a situation like the one I posted above in a
> geometrically reduced system: it will get way too confu
2009/9/19 John Smith :
> 2009/9/19 Martin Koppenhoefer :
>
>> what do you mean? We are already doing this: lanes=3
>
> That only says how many lanes, it doesn't describe restrictions or
> properties of individual lanes.
>
>> In simple cases you don't need it, and when it get's complex, IMHO
>> expl
2009/9/20 Mike Harris :
> Claudius - I think you may have answered the question I just asked - thanks
> - I must admit that I hadn't seen this proposal before. Once again,
> relations prove powerful!
Yes except they get abused when we should be looking towards
micromapping techniques, not hacks to
Claudius - I think you may have answered the question I just asked - thanks
- I must admit that I hadn't seen this proposal before. Once again,
relations prove powerful!
Mike Harris
> -Original Message-
> From: Claudius [mailto:claudiu...@gmx.de]
> Sent: 19 September 2009 14:12
> To: t
>From time to time I have a related problem, viz. a bridge carrying a public
>right of way and crossing both a physical feature, e.g. a river, and an
>administrative boundary. The result is that the ref= key changes value on the
>boundary, typically in the middle of the river, thus creating two
Ævar Arnfjörð Bjarmason schrieb:
> On Sat, Sep 19, 2009 at 1:21 PM, dom Team OiD wrote:
>> Hi,
>>
>> I'm sure such a tool is really cool stuff. I already experimented with
>> easy installer, whcih is creating msi packaes for windows.
>> I didn't use your installer, so this question comes up.
>> Wh
At work we've released for beta testing a POI mapping app for both
BlackBerry and Android, with future plans for iPhone, Windows Mobile
and Symbian.
Already it's receiving favourable reviews from non-OSM mappers.
http://www.blackberryinsight.com/2009/09/19/bigtincan-mapper-acts-as-the-best-gps-in
Martin Koppenhoefer wrote:
> 2009/9/19 John Smith :
>> 2009/9/19 Martin Koppenhoefer :
>>> don't get you. Isn't "mapping lanes" just the same like what I
>>> suggested? I'm in favour of mapping all lanes and ways as well, but
>>> you DO need relations to combine them into streets (indicating kind o
2009/9/19 Martin Koppenhoefer :
> what do you mean? We are already doing this: lanes=3
That only says how many lanes, it doesn't describe restrictions or
properties of individual lanes.
> In simple cases you don't need it, and when it get's complex, IMHO
> explicit mapping is the only transparen
On Sat, Sep 19, 2009 at 1:21 PM, dom Team OiD wrote:
> Hi,
>
> I'm sure such a tool is really cool stuff. I already experimented with
> easy installer, whcih is creating msi packaes for windows.
> I didn't use your installer, so this question comes up.
> What is the benefit of your installer compa
2009/9/19 Frederik Ramm :
> Hi,
>
> John Smith wrote:
>>>
>>> I would recommend a relation to unify "several bridges" in one (which
>>> gets also the name). Not really more simple to map, but resulting more
>>> accurate and probably could also render nicer.
>>
>> That seems like such a nasty way to
2009/9/19 John Smith :
> 2009/9/19 Martin Koppenhoefer :
>> don't get you. Isn't "mapping lanes" just the same like what I
>> suggested? I'm in favour of mapping all lanes and ways as well, but
>> you DO need relations to combine them into streets (indicating kind of
>> separation and / or possibil
Hi,
John Smith wrote:
>> I would recommend a relation to unify "several bridges" in one (which
>> gets also the name). Not really more simple to map, but resulting more
>> accurate and probably could also render nicer.
>
> That seems like such a nasty way to do it, this is why I've suggested
> al
2009/9/19 Martin Koppenhoefer :
> don't get you. Isn't "mapping lanes" just the same like what I
> suggested? I'm in favour of mapping all lanes and ways as well, but
> you DO need relations to combine them into streets (indicating kind of
> separation and / or possibility to change lanes). I was i
2009/9/19 John Smith :
> 2009/9/19 Martin Koppenhoefer :
>
>> I would recommend a relation to unify "several bridges" in one (which
>> gets also the name). Not really more simple to map, but resulting more
>> accurate and probably could also render nicer.
>
> That seems like such a nasty way to do
Am 19.09.2009 14:39, Martin Koppenhoefer:
> 2009/9/19 d f:
>> Hi
>>
>> I have a bridge carrying a cycle lane, dual carriage way (with central
>> reservtion)& footpath. As far as I can see is they each need there own
>> bridge& the result gets a bit crowded.
>>
>> Is there a way to simplify this?
2009/9/19 Martin Koppenhoefer :
> I would recommend a relation to unify "several bridges" in one (which
> gets also the name). Not really more simple to map, but resulting more
> accurate and probably could also render nicer.
That seems like such a nasty way to do it, this is why I've suggested
a
2009/9/19 d f :
> Hi
>
> I have a bridge carrying a cycle lane, dual carriage way (with central
> reservtion) & footpath. As far as I can see is they each need there own
> bridge & the result gets a bit crowded.
>
> Is there a way to simplify this?
> If the bright was independent it could also mean
Hi
I have a bridge carrying a cycle lane, dual carriage way (with central
reservtion) & footpath. As far as I can see is they each need there own bridge
& the result gets a bit crowded.
Is there a way to simplify this?
If the bright was independent it could also mean that the ways wouldn't need
shop=vacant; empty stores should be marked vacant, not removed from map.
I think this is fine. shop=foo disused=yes doesn't work because often
the idenity of a shop is removed as the landlord gets ready to re-lease,
and it's just an empty room.
shop=supplements; specialty food and dietary
I've written a free installation program for Garmin's MapSource. It's
aimed at the people who are maintaining Garmin map exports of the
OpenStreetMap database. A lot of these exports[1] don't have a
MapSource installer, some suggest proprietary solutions and some have
a unconfigurable BAT file incl
Am Samstag 19 September 2009 schrieb Maarten Deen:
> I just saw an item on OSM in (a rerun) of Quarks & Co on the German TV
> station WDR. It was about mapping the inner city of Bonn for wheelchairs.
> Nice example of micromapping, where mappers were even measuring the height
> of the curbs and
I just saw an item on OSM in (a rerun) of Quarks & Co on the German TV station
WDR. It was about mapping the inner city of Bonn for wheelchairs. Nice example
of micromapping, where mappers were even measuring the height of the curbs and
inclination of streets (both very important for wheelchair
41 matches
Mail list logo
