#3715: Add a box sport= when tagging a pitch
-+--
Reporter: Karto| Owner: potlatch-dev@…
Type: enhancement | Status: new
Priority: major|
#3713: Cannot type accentuated characters from French keyboard
+---
Reporter: Karto | Owner: potlatch-dev@…
Type: defect | Status: closed
Priority:
#3715: Add a box sport= when tagging a pitch
-+--
Reporter: Karto| Owner: potlatch-dev@…
Type: enhancement | Status: new
Priority: trivial |
#3719: Misspelled preset value (ruin-ruins)
---+
Reporter: RM87 | Owner: potlatch-dev@…
Type: defect | Status: new
Priority: minor | Milestone:
#3714: Add option building / ruins / none in menu when tagging an area
---+
Reporter: Karto | Owner: potlatch-dev@…
Type: defect | Status: new
Priority:
#3714: Add option building / ruins / none in menu when tagging an area
---+
Reporter: Karto | Owner: potlatch-dev@…
Type: defect | Status: new
Priority:
#3719: Misspelled preset value (ruin-ruins)
---+
Reporter: RM87 | Owner: potlatch-dev@…
Type: defect | Status: new
Priority: minor | Milestone:
Hello,
I am extremely interested in the development of Areas in OSM - it seems to me
to be an OSM lacking/logical necessity - yet there seems to be little
discussion on the matter. Could we exchange some ideas on the main article's
(http://wiki.openstreetmap.org/wiki/The_Future_of_Areas)
Hi,
the.promena...@gmail.com wrote:
I am extremely interested in the development of Areas in OSM - it
seems to me to be an OSM lacking/logical necessity - yet there seems
to be little discussion on the matter. Could we exchange some ideas
on the main article's
Frederik Ramm wrote:
I would prefer to use the mailing list for discussion.
+1.
3. For editors - add support for area datatype. For most editors
this will probably be a relatively small change
The code will be easy, yes. Devising a coherent and intuitive UI for it may
not be.
cheers
The transition would be a stickler for sure. I think the best thing to do would
be to a) define the new schema in a concrete way, b) create a new dataset with
data 'translated' from the old version c) 'freeze' the old dataset (no new
contributions there) and d) have both run parallelly to give
On 25. 04. 11 11:41, Richard Fairhurst wrote:
Frederik Ramm wrote:
I would prefer to use the mailing list for discussion.
+1.
3. For editors - add support for area datatype. For most editors
this will probably be a relatively small change
The code will be easy, yes. Devising a coherent and
2011/4/25 Frederik Ramm frede...@remote.org:
A big question would be the transition from the old model to the new, things
like:
b) How exactly will we transform old-style areas into new-style areas? Can
object history be preserved (very desirable!), and if so, how?
also: which of the old
Mâ¡rtin Koppenhoefer wrote:
2011/4/25 Frederik Ramm frede...@remote.org:
A big question would be the transition from the old model to the new,
things
like:
b) How exactly will we transform old-style areas into new-style areas?
Can
object history be preserved (very desirable!), and if so,
On 25-4-2011 13:31, Jukka Rahkonen wrote:
also: which of the old data is most probably an area and which is a
closed linear feature. This might not be clear in all cases.
Not in all cases, but the overwhelming majority of them are clear.
And further: There are some badly invalid area
Hi Richard,
I would prefer to use the mailing list for discussion.
+2.
The mailing list is a lot like ASCII - as a programmer, it makes me feel
safe. :-)
3. For editors - add support for area datatype. For most editors
this will probably be a relatively small change
The code will be
also: which of the old data is most probably an area and which is a
closed linear feature. This might not be clear in all cases.
Not in all cases, but the overwhelming majority of them are clear.
Right, and the ones that defy mechanical translation are the ones that
cause OSM clients to be
Ben Supnik wrote:
wouldn't an editor already have a cherent and intuitive UI in the form
of multipolygon relation editing?
P2 doesn't yet have a specialised interface for drawing a multipolygon.
I'm intending to add a toolbox icon for one in the medium term (draw two
closed ways; select
also: which of the old data is most probably an area and which is a
closed linear feature. This might not be clear in all cases.
But doesn't an end-user's software have to figure this out already? Another
question - how does OSM do this?
On Apr 25, 2011, at 13:10 , M∡rtin Koppenhoefer wrote:
But doesn't an end-user's software have to figure this out already? Another
question - how does OSM do this?
OSM is not one single piece of software, so I'm not sure you can say
how does OSM do this? You'd have to talk about a specific app, e.g.
mapnik or osm2xp or any of the many other
Toby Murray toby.mur...@gmail.com wrote:
osmosis --read-pbf france.osm.pbf \
--tf accept-ways place=* \
--tf accept-nodes place=*
--tf accept-relations place=*
--write-xml france_place.osm
After some tests i cant run osmosis...
My config
Hi,
Pierre-Alain Dorange wrote:
./osmosis --rb france.osm.pbf -tf accept-nodes place=* --wx
fr_places.osm
You're missing the second - before tf, making Osmosis think that
-tf was a second argument to --rb.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09
Frederik Ramm frede...@remote.org wrote:
./osmosis --rb france.osm.pbf -tf accept-nodes place=* --wx
fr_places.osm
You're missing the second - before tf, making Osmosis think that
-tf was a second argument to --rb.
Oh my god, shame on me.
Thanks.
--
Pierre-Alain Dorange
OSM
Hi all!
Google just announced [0] the students participating in the 2011 Summer of
Code program. Three student proposals were accepted this year from a group
of 17 applications. I'm excited to have the following student projects
sponsored by Google this Summer:
- Improvements to the Open
24 matches
Mail list logo
