Hi Steve, how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted? Is it possible that there is another attribute besides ODD,EVEN,BOTH ? Gerd
Hi Gerd
how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted?
Is it possible that there is another attribute besides ODD,EVEN,BOTH ?
No, you just have a range consisting of the one number to that same number. eg E,42,42. If there are several random numbers on a segment of road then you would have to introduce new flagged nodes at appropriate places along the road. By flagged node I mean that it has what we call the extra-bit set. See LinePreparer. Currently I believe that we only set this bit on road junction nodes, but it can be set on any point in the road. Unfortunately there may be assumptions in the routing code about usage of the extra bit, since we didn't know that until house numbers. The house number code should be OK in that respect though. Also when adding extra nodes along the road you would have to be careful that they are not removed by any of the simplifying filters. ..Steve
Hi Steve, thanks, I'll have a closer look at this. With a little bit of luck I just have to call Coord.incHighwayCount(), IIRC there should be no code that fails when the counter is > 1 without being a a road junction. Gerd
Date: Mon, 22 Dec 2014 10:17:27 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] random housenumbers
Hi Gerd
how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted?
Is it possible that there is another attribute besides ODD,EVEN,BOTH ?
No, you just have a range consisting of the one number to that same number. eg E,42,42.
If there are several random numbers on a segment of road then you would have to introduce new flagged nodes at appropriate places along the road.
By flagged node I mean that it has what we call the extra-bit set. See LinePreparer. Currently I believe that we only set this bit on road junction nodes, but it can be set on any point in the road. Unfortunately there may be assumptions in the routing code about usage of the extra bit, since we didn't know that until house numbers. The house number code should be OK in that respect though.
Also when adding extra nodes along the road you would have to be careful that they are not removed by any of the simplifying filters.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, maybe you can help me with that? I seem to have no img file with an example. I guess we have to 1) add a flag to RouteNode which says whether or not the node is used for routing. A RouteNode for housenumbers will have arcs like a normal one, but they are only used to allow placing the housenumber infos. 2) change RoadDef.writeNod2() to create the bitstream using this flag. 3) What happens with the complex routing routines in RouteNode, e.g. addArcsToMajorRoads() ? Do we have to add arcs to the "housenumber nodes" ? 4) In StyledConverter I see a call road.setStartsWithNode(nodeIndices.get(0) == 0); which seems to always set the bit to true. The code in RoadHelper may be work different. Do you have an example that explains this? Attached patch shows how I intend to implement the random housenumbers, it doesn't do anything useful yet. Maybe you can tell me if I am on the right way? Gerd
Date: Mon, 22 Dec 2014 10:17:27 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] random housenumbers
Hi Gerd
how can I make sure that Garmin programs do not try to interpolate housenumbers for places where this is not wanted?
Is it possible that there is another attribute besides ODD,EVEN,BOTH ?
No, you just have a range consisting of the one number to that same number. eg E,42,42.
If there are several random numbers on a segment of road then you would have to introduce new flagged nodes at appropriate places along the road.
By flagged node I mean that it has what we call the extra-bit set. See LinePreparer. Currently I believe that we only set this bit on road junction nodes, but it can be set on any point in the road. Unfortunately there may be assumptions in the routing code about usage of the extra bit, since we didn't know that until house numbers. The house number code should be OK in that respect though.
Also when adding extra nodes along the road you would have to be careful that they are not removed by any of the simplifying filters.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
I guess we have to 1) add a flag to RouteNode which says whether or not the node is used for routing. A RouteNode for housenumbers will have arcs like a normal one, but they are only used to allow placing the housenumber infos.
I don't think the change will involve RouteNode. Currently we have road lines made up of Coord and CoordNode. There should be something between those two. Lets call it NumberCoord here for want of a better name. Add a method to Coord that returns false. class Coord { public boolean isNumberNode() { return false; } } // Then NumberCoord extends that and overrides it to return true. class NumberCoord extends Coord { ... isNumberNode() { return true; } } Then CoordNode extends NumberCoord. Then in LinePreparer around line 380 where it says: * Current thought is that the node indicator is set when * the point is a node. There's a separate first extra bit * that always appears to be false. The last points' extra bit * is set if the point is a node and this is not the last * polyline making up the road. * Todo: special case the last bit The comment needs the 'current thought' changing ;) Then use co.isNumberNode() instead of co.getId()
2) change RoadDef.writeNod2() to create the bitstream using this flag. 3) What happens with the complex routing routines in RouteNode, e.g. addArcsToMajorRoads() ?
I don't think you would have to change any of that so long as there are no invalid assumptions in there.
Do we have to add arcs to the "housenumber nodes" ?
No. Well you could but then they would be routing nodes ;)
4) In StyledConverter I see a call road.setStartsWithNode(nodeIndices.get(0) == 0); which seems to always set the bit to true. The code in RoadHelper may be work different. Do you have an example that explains this?
I believe that code is intended to deal with the case where the first node is a dead end.
Attached patch shows how I intend to implement the random housenumbers, it doesn't do anything useful yet. Maybe you can tell me if I am on the right way?
I think that is probably not the place to start as explained above. Sorry I may have been misleading as there are so many things called Node. We need some new terms! The NetCheck program was written after this was understood so it will correctly display housenumbers in this case. The output is a bit verbose, just look for the Number lines. ..Steve
Hi Steve, thanks, don't know what I have missed before that I went so wrong :-O Two open questions: 1) Why do we need the new class NumberCoord? I'd say we just have to use one of the spare bits in the Coord.flags field. Major problem is to find all places where we create copies of existing Coord instances and make sure that the info is copied properly? 2) Is a CoordNode always also a number node? Or is it possible to combine the numbers for multiple arcs? I guess that would allow to save some bytes. Gerd
Date: Thu, 8 Jan 2015 23:26:04 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] random housenumbers
Hi Gerd
I guess we have to 1) add a flag to RouteNode which says whether or not the node is used for routing. A RouteNode for housenumbers will have arcs like a normal one, but they are only used to allow placing the housenumber infos.
I don't think the change will involve RouteNode.
Currently we have road lines made up of Coord and CoordNode. There should be something between those two. Lets call it NumberCoord here for want of a better name.
Add a method to Coord that returns false.
class Coord { public boolean isNumberNode() { return false; } }
// Then NumberCoord extends that and overrides it to return true. class NumberCoord extends Coord { ... isNumberNode() { return true; } } Then CoordNode extends NumberCoord.
Then in LinePreparer around line 380 where it says:
* Current thought is that the node indicator is set when * the point is a node. There's a separate first extra bit * that always appears to be false. The last points' extra bit * is set if the point is a node and this is not the last * polyline making up the road. * Todo: special case the last bit
The comment needs the 'current thought' changing ;)
Then use co.isNumberNode() instead of co.getId()
2) change RoadDef.writeNod2() to create the bitstream using this flag. 3) What happens with the complex routing routines in RouteNode, e.g. addArcsToMajorRoads() ?
I don't think you would have to change any of that so long as there are no invalid assumptions in there.
Do we have to add arcs to the "housenumber nodes" ?
No. Well you could but then they would be routing nodes ;)
4) In StyledConverter I see a call road.setStartsWithNode(nodeIndices.get(0) == 0); which seems to always set the bit to true. The code in RoadHelper may be work different. Do you have an example that explains this?
I believe that code is intended to deal with the case where the first node is a dead end.
Attached patch shows how I intend to implement the random housenumbers, it doesn't do anything useful yet. Maybe you can tell me if I am on the right way?
I think that is probably not the place to start as explained above. Sorry I may have been misleading as there are so many things called Node. We need some new terms!
The NetCheck program was written after this was understood so it will correctly display housenumbers in this case. The output is a bit verbose, just look for the Number lines.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
Two open questions: 1) Why do we need the new class NumberCoord?
There is always more than one way to do anything... so no you don't need it. I suggested it because it requires no memory and it expresses the relationship that a CoordNode is a NumberNode.
2) Is a CoordNode always also a number node? Or is it possible
Yes a CoordNode is a number node.
to combine the numbers for multiple arcs? I guess that would allow to save some bytes.
You can skip number nodes if there are no known numbers on that part of the road. But otherwise it is from number node to number node. Arc is a NOD concept, house numbers are purely a NET concept. I know that we don't support a NET only build but if we did it could have house numbers without any routing at all. ..Steve
Hi Steve,
1) Why do we need the new class NumberCoord?
There is always more than one way to do anything... so no you don't need it. I suggested it because it requires no memory and it expresses the relationship that a CoordNode is a NumberNode.
OK, my reason for prefering the bit flag is that it allows to change a normal coord to a "NumberCoord" without allocating a new object. I think that makes life easier.
2) Is a CoordNode always also a number node? Or is it possible
Yes a CoordNode is a number node.
to combine the numbers for multiple arcs? I guess that would allow to save some bytes.
You can skip number nodes if there are no known numbers on that part of the road. But otherwise it is from number node to number node. Arc is a NOD concept, house numbers are purely a NET concept. I know that we don't support a NET only build but if we did it could have house numbers without any routing at all.
OK, I may try to code the support for NET without NOD later. Gerd
participants (2)
-
Gerd Petermann -
Steve Ratcliffe