[pgrouting-dev] OSX build error

[Alec Gosse]

Yes, that fixed it. Thank you.

Meanwhile I'm running into a strange issue using the edge version of trsp. I wanted to weed out unroutable fragments on the edge of my network by testing for a valid route to the center. I've gotten as far as noting that when the isolated fragment is the destination, the function returns path not found, however when it is the source, the route magically jumps to the other side of the graph and then continues to the target?

This does not seem to happen if specifying source and target vertices.

Alec




On May 28, 2013, at 11:31 PM, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

> Duh! I must have missed that one. That is a know issue and I thought I caught all of them, but I guess not. Fix just pushed, please try again.
> 
> Thank you for the reports and your patience.
> 
> -Steve
> 
> On 5/28/2013 9:59 PM, Alec Gosse wrote:
>> Here's the new compile result:
>> 
>> /usr/local/include/boost/graph/detail/adjacency_list.hpp:2655:27: error: cannot form a reference to 'void'
>>         typedef value_type& reference;
>> 
>> /usr/local/include/boost/graph/detail/adjacency_list.hpp:2656:33: error: cannot form a reference to 'void'
>>         typedef const value_type& const_reference;
>>                                 ^
>> 
>> /usr/local/src/pgrouting_main/src/kdijkstra/src/k_targets_boost_wrapper.cpp:285:48: error: use of undeclared identifier 'weightmap'; did you mean
>>       'weight_map'?
>>     property_map<graph_t, edge_weight_t>::type weightmap = get(edge_weight, graph);
>>                                                ^~~~~~~~~
>>                                                weight_map
>> 
>> Alec
>> 
>> 
>> 
>> 
>> On May 28, 2013, at 7:38 PM, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>> 
>>> OK, I did more research and I might have a fix for this. I just pushed some updated code. Let me know how that works out.
>>> 
>>> -Steve
>>> 
>>> On 5/28/2013 5:17 PM, Stephen Woodbridge wrote:
>>>> On 5/28/2013 4:38 PM, Alec Gosse wrote:
>>>>> Sorry, that did not fix the issue:
>>>>> /usr/local/src/pgrouting_main/src/kdijkstra/src/k_targets_boost_wrapper.cpp:341:31:
>>>>> error: variable length array of non-POD element type
>>>>>       'std::vector<int>'
>>>>>     std::vector<int> path_vect[nb_targets];
>>>>>                               ^
>>>> 
>>>> What happens if you change this from:
>>>> 
>>>> std::vector<int> path_vect[nb_targets];
>>>> 
>>>> to:
>>>> 
>>>> std::vector<int> path_vect(nb_targets);
>>>> 
>>>> I just guessing here, so someone with C++ experience please jump in!
>>>> 
>>>> -Steve
>>>> 
>>>>> This link:
>>>>> http://stackoverflow.com/questions/9550712/variable-length-array-of-non-pod-element-type-string-aka-basic-stringchar
>>>>> 
>>>>> suggests that the code relies on a g++ extension of the language
>>>>> standard?
>>>>> 
>>>>> Alec
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On May 28, 2013, at 4:15 PM, Stephen Woodbridge
>>>>> <woodbri at swoodbridge.com> wrote:
>>>>> 
>>>>>> I made these changes and they compile and work in linux, so I just
>>>>>> pushed them. do another pull and try again.
>>>>>> 
>>>>>> Let me know how that goes,
>>>>>>  -Steve
>>>>>> 
>>>>>> On 5/28/2013 4:11 PM, Stephen Woodbridge wrote:
>>>>>>> Actually, it looks like there are two occurances that need to be
>>>>>>> changed.
>>>>>>> 
>>>>>>> -Steve
>>>>>>> 
>>>>>>> On 5/28/2013 4:07 PM, Stephen Woodbridge wrote:
>>>>>>>> On 5/28/2013 3:51 PM, Alec Gosse wrote:
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> I just pulled the latest in the sew_devel_2-0 branch and got the
>>>>>>>>> following compiler error under Mac 10.8.
>>>>>>>>> 
>>>>>>>>> /usr/local/src/pgrouting_main/src/kdijkstra/src/k_targets_boost_wrapper.cpp:341:26:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> error: variable length array of non-POD element type
>>>>>>>>>       'vector<int>'
>>>>>>>>>     vector<int> path_vect[nb_targets];
>>>>>>>>> 
>>>>>>>>> I can confirm that this does not occur on my Ubuntu machine.
>>>>>>>> 
>>>>>>>> Hi Alec,
>>>>>>>> 
>>>>>>>> I'm not very good with C++, but as a guess, can you edit that line 341
>>>>>>>> and change it from:
>>>>>>>> 
>>>>>>>> vector<int> path_vect[nb_targets];
>>>>>>>> 
>>>>>>>> to:
>>>>>>>> 
>>>>>>>> std::vector<int> path_vect[nb_targets];
>>>>>>>> 
>>>>>>>> 
>>>>>>>> And let me know if that fixes your compile problem.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>>   -Steve
>>>>>>>> _______________________________________________
>>>>>>>> pgrouting-dev mailing list
>>>>>>>> pgrouting-dev at lists.osgeo.org
>>>>>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> pgrouting-dev mailing list
>>>>>>> pgrouting-dev at lists.osgeo.org
>>>>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> pgrouting-dev mailing list
>>>>>> pgrouting-dev at lists.osgeo.org
>>>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>> 
>>>>> _______________________________________________
>>>>> pgrouting-dev mailing list
>>>>> pgrouting-dev at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> pgrouting-dev mailing list
>>>> pgrouting-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>> 
>>> _______________________________________________
>>> pgrouting-dev mailing list
>>> pgrouting-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>> 
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>> 
> 
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev